Better tools for kernel developers [LWN.net]

Better tools for kernel developers

Posted Feb 6, 2020 23:15 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (5 responses)

Most of my interactions with the world of email happen via port 443, not port 25.

Better tools for kernel developers

Posted Feb 7, 2020 11:42 UTC (Fri) by meyert (subscriber, #32097) [Link] (4 responses)

Port 25 ist the SMTP server to server port anyway....you probably want SMTP submission protocol port 587

Better tools for kernel developers

Posted Feb 7, 2020 12:01 UTC (Fri) by Karellen (subscriber, #67644) [Link] (3 responses)

Port 25 can also be used, as it was used for years, and can still be used, by all email servers that I am aware of, as the client-to-server email submission port.

Port 587 is completely redundant. It even uses the exact same protocol as that which runs on port 25. You can just set up your firewall rules to translate traffic on port 587 to port 25, and email submission will still work without any other changes. Just use port 25.

Better tools for kernel developers

Posted Feb 7, 2020 18:37 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

The advantage of using port 587 for client submission is that as a mail server operator you get to apply a different set of policies to connections on that port. For example, submitting e-mail on port 587 often requires the STARTTLS and SMTP-AUTH features (among others), which you can't insist on for server-to-server e-mail delivery on port 25.

In point of fact, various ISPs block clients from accessing TCP port 25 anywhere on the Internet, and force them to submit e-mail on the ISP's own mail servers on port 587 with encryption and authentication (and possibly rate-limited), as a spam-reduction measure.

Better tools for kernel developers

Posted Feb 7, 2020 19:23 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

In point of fact, various ISPs block clients from accessing TCP port 25 anywhere on the Internet, and force them to submit e-mail on the ISP's own mail servers on port 587 with encryption and authentication (and possibly rate-limited), as a spam-reduction measure.

I think this gets to the core problem with email as a tool: it no longer works the way people expect it to. Spam and the responses to spam have fundamentally broken email. It is no longer easy to set up a server that reliably communicates with the rest of the world. Demanding that developers use a particular email setup in order to work on the kernel is thus a serious barrier to entry.

Better tools for kernel developers

Posted Feb 11, 2020 10:44 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

587 is not redundant at all. You will typically open 25 without auth (to receive third-party messages), and 587 with auth (to allow your users to create new messages). The security pipeline is different.

Better tools for kernel developers

Posted Feb 6, 2020 23:15 UTC (Thu) by dannyobrien (subscriber, #25583) [Link] (9 responses)

When I find that I cannot comprehend something, I usually discover that I have to work harder on my own comprehension abilities.

For instance, as far as I can see, people here are describing challenges that revolve around sending and receiving email in the specific way that git expects, rather than expressing an inability to send or reply to email in general. Most people have email set-ups that don't work the way that git assumes (including you, I think! You do have a gmail account, yes?), and struggle to find out strategies that can enable them to better work with it.

Better tools for kernel developers

Posted Feb 7, 2020 1:52 UTC (Fri) by lsl (subscriber, #86508) [Link] (8 responses)

Gmail works just fine with git-send-email (or /usr/sbin/sendmail, ...). You generate an app-specific access token in the web UI and submit to smtp.gmail.com on port 587.

Better tools for kernel developers

Posted Feb 7, 2020 2:04 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (2 responses)

Though in all fairness that is going to change as soon as Google, in all their wisdom, only allows oauth authentication for SMTP and IMAP.

Better tools for kernel developers

Posted Feb 7, 2020 15:56 UTC (Fri) by jgg (subscriber, #55211) [Link] (1 responses)

I've been working on this for a while now, and am getting close to keeping my mutt & exim kernel workflow scheme working post-oauth-apocalypse.

https://github.com/jgunthorpe/cloud_mdir_sync

I have mail inflow working using OAUTH and a REST transport from my Office365 and GMail accounts.

While it seems trivial to say 'oh just use OAUTH' it actually turned out to be quite difficult to wrangle all the peices properly.

I haven't put the last parts in to send email yet, but internally the tool does have the bearer token to authorize SMTP. It needs plumbing into the MTA. Maybe next month. Still waiting for Office365 to actually have a way to send raw email with OAUTH, as MS promised to finally do 4 months ago. Maddening.

But yes, setting this all up is expert level stuff, not something you could expect someone who wants to just use git send-email to sort out. I'm mildly hopeful that someone will build a git plugin that can send email through gmail/o365 fully natively with 0 configuration.. At least for gmail sending email via REST is fairly straightfoward once you get the OAUTH token.

Better tools for kernel developers

Posted Feb 7, 2020 16:23 UTC (Fri) by pizza (subscriber, #46) [Link]

> But yes, setting this all up is expert level stuff, not something you could expect someone who wants to just use git send-email to sort out.

...but it only takes an expert like you to figure it out once, and then it's a lot simpler for other folks to replicate it.

> I'm mildly hopeful that someone will build a git plugin that can send email through gmail/o365 fully natively with 0 configuration.

That might be a natural progression of the work you're doing right now, and I suspect it would be very well received..

Better tools for kernel developers

Posted Feb 7, 2020 4:04 UTC (Fri) by Conan_Kudo (subscriber, #103240) [Link] (4 responses)

And if your Gsuite admin doesn't allow creating app tokens (mainly to force all authentication through 2FA through custom auth), what do you do then?

Better tools for kernel developers

Posted Feb 7, 2020 4:51 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

...Then you quit, in favour of an organization that knows better than to try and force its engineering staff to use the same tools and workflows as its secretaries?

(I'm actually serious here; this sort of thing is the tip of several pathological icebergs...)

Better tools for kernel developers

Posted Feb 8, 2020 23:25 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (2 responses)

This is an unreasonable response. I can count on one hand the number of projects that $DAYJOB relies on that still use email-based workflows for submitting fixes. (Hint: it's only three, and one we don't usually contribute to!) That's out of literally hundreds of projects and the three Linux distributions we contribute to.

There are a number of other concerns that prevent enabling weak app tokens. Most of them are around compliance and preventing account hijacking. Accounts of engineers are often way more privileged than non-engineers. At $DAYJOB, compliance requirements have forced us to mandate it for everyone since we try to maintain a relatively open environment for employees in the company.

As an aside, executive assistants (who you call "secretaries") tend to handle pretty sensitive stuff, and they're usually quite smart. They handle a different problem domain than engineers do, and it's a hard one. I miss being able to ask one to help me with doing travel arrangements and payment work. Doing it myself is a lot of complicated work...

Better tools for kernel developers

Posted Feb 9, 2020 3:59 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> As an aside, executive assistants (who you call "secretaries") tend to handle pretty sensitive stuff, and they're usually quite smart. They handle a different problem domain than engineers do, and it's a hard one.

Well, of course "secretaries" handle a (very) different problem domain than engineers. (And one of their more challenging responsibilities is insulating executives from the effects of their own policies)

...Meanwhile, that is precisely why each group should have tools catering to their particular needs.

Better tools for kernel developers

Posted Feb 21, 2020 21:36 UTC (Fri) by Wol (subscriber, #4433) [Link]

And Secretaries handle a different domain again ... (sorry, it's one of my pet peeves, my mum was a Secretary and it is a serious legal qualification...)

Cheers,
Wol

Better tools for kernel developers

Posted Feb 6, 2020 23:24 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (13 responses)

This is a straw man. Plenty of people have perfectly valid email accounts, capable of exchanging messages with any other email account, but no straightforward way to use them with git-send-mail. Webmail and Exchange users probably outnumber traditional SMTP/POP3/IMAP clients at this point, and by a large margin.

Better tools for kernel developers

Posted Feb 7, 2020 11:00 UTC (Fri) by marcthe12 (subscriber, #135461) [Link] (12 responses)

Not to mention some of these issues are either caused by some company using such providers for email mainly gsuite and exchange. Not to mention some peoplemaybe having some email from school days and maybe unwill change email address for example. there need to wrappers for webmail provider to deal with non standard protocols or other auth method (oAuth2 or 2-FA) so they can be used with tradition workflows.

Better tools for kernel developers

Posted Feb 7, 2020 12:58 UTC (Fri) by pizza (subscriber, #46) [Link] (11 responses)

So.. the highly-successful and supremely-productive linux kernel development process needs to rethink its tooling because your employer deliberately chose to use (and configure) its email systems without considering the needs of its engineering staff?

The entire Linux kernel mentality is centered around Fixing Things the Right Way(tm), ie identifying the root cause of problems rather than adding endless layers of workarounds, and that extends to its tooling. If the tools are shitty, then make better ones. Telling them that they need to throw out the tooling they built to be maximally productive because other folks insist on using shitty tooling is not an argument that will gain traction.

Better tools for kernel developers

Posted Feb 7, 2020 17:53 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> So.. the highly-successful and supremely-productive linux kernel development process needs to rethink its tooling because your employer deliberately chose to use (and configure) its email systems without considering the needs of its engineering staff?
Is it super-productive, though?

Better tools for kernel developers

Posted Feb 7, 2020 20:28 UTC (Fri) by roc (subscriber, #30627) [Link] (3 responses)

> your employer deliberately chose to use (and configure) its email systems without considering the needs of its engineering staff?

When you set up an email system you can't know whether, possibly years in the future, your engineers might need to contribute to the kernel.

Better tools for kernel developers

Posted Feb 7, 2020 20:56 UTC (Fri) by pizza (subscriber, #46) [Link] (2 responses)

> When you set up an email system you can't know whether, possibly years in the future, your engineers might need to contribute to the kernel.

You're right, at any given point in time, you can't absolutely know what your users will need at some point in the future, which is why there must be a process for new needs/requirements to be captured, evaluated, and supported. After all, IT is a strategic asset that empowers your colleagues to leverage agile design methodologies to deliver maximum value through effective business analysis to diverse stakeholders while upholding the highest standards of quality and integrity.

Meanwhile, back in the real world, every engineering group I've ever worked for/with has had to set up some sort of shadow IT infrastructure in order to do their jobs.

Better tools for kernel developers

Posted Feb 7, 2020 21:56 UTC (Fri) by geert (subscriber, #98403) [Link] (1 responses)

IT seems to be the only infrastructure where the business people tend to decide/veto decisions for the technical people.
Imagine all transports had to be performed using limousines instead of trucks, as the former "just work fine" for the business people.

Better tools for kernel developers

Posted Feb 7, 2020 22:43 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

> IT seems to be the only infrastructure where the business people tend to decide/veto decisions for the technical people.

Business people are perfectly capable of making terrible decisions about infrastructural matters in all sorts of domains; the Chemical Safety and Hazard Investigation Board would have a lot less to post on their Youtube channel if this wasn't the case.

Better tools for kernel developers

Posted Feb 8, 2020 13:17 UTC (Sat) by gfernandes (subscriber, #119910) [Link] (5 responses)

>>The entire Linux kernel mentality is centered around Fixing Things the Right Way(tm)

...by using the **wrong** tool (aka email)?

Email may have been the **only** way to get things done in the 70's. But that's not too say it was the **right** tool then. Most certainly, it is **not** the right tool **now**.

Better tools for kernel developers

Posted Feb 9, 2020 0:22 UTC (Sun) by andyc (subscriber, #1130) [Link]

> ...by using the **wrong** tool (aka email)?

> Email may have been the **only** way to get things done in the 70's. But that's not too say it was the **right** tool then.
> Most certainly, it is **not** the right tool **now**.

Opinions vary...

Better tools for kernel developers

Posted Feb 9, 2020 4:05 UTC (Sun) by pizza (subscriber, #46) [Link] (3 responses)

Email remains the *only* fully federated communication tool out there.

Everything else has dissolved into balkanized silos whose primary goal is to monetize the user.

Better tools for kernel developers

Posted Feb 12, 2020 17:37 UTC (Wed) by flussence (guest, #85566) [Link] (2 responses)

XMPP works well too, now that the silos have given up trying and failing to weaponise it against each other.

Better tools for kernel developers

Posted Feb 12, 2020 17:56 UTC (Wed) by pizza (subscriber, #46) [Link]

The entire federated XMPP userbase is barely a rounding error when compared to even one of the current IM silos.

...And if you think getting a usable semi-custom email workflow is too difficult... XMPP is an order of magnitude worse, with significantly worse tooling.

(I still have an XMPP server going for my domains. In the past few years, I've received a total of *zero* non-spam messages..)

Better tools for kernel developers

Posted Feb 12, 2020 18:06 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> XMPP works well too, now that the silos have given up trying and failing to weaponise it against each other.

XMPP has failed to get any traction because none of the implementations could be expected to be reasonably compatible with each other. That was the practical consequence of being extensible and having different features bolted on. Matrix has higher momentum now

Better tools for kernel developers

Posted Feb 8, 2020 13:09 UTC (Sat) by gfernandes (subscriber, #119910) [Link] (2 responses)

It's actually quite easy.

Email is so fantastically unfit for purpose, it's not even worth talking about.

WhatsApp and Signal have long replaced email for person-to-person communication for me. It's encrypted by default, and doesn't require me pulling out my hair out gauging out the eyes of whoever I want to communicate with, to setup encrypted communications.

Try doing that with email without getting granny to jump off the cliff.

Better tools for kernel developers

Posted Feb 21, 2020 21:39 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> WhatsApp and Signal have long replaced email for person-to-person communication for me. It's encrypted by default, and doesn't require me pulling out my hair out gauging out the eyes of whoever I want to communicate with, to setup encrypted communications.

I avoid WhatsApp, and what on earth is Signal?????

Cheers,
Wol

Better tools for kernel developers

Posted Feb 22, 2020 19:09 UTC (Sat) by jem (subscriber, #24231) [Link]

You know, nowadays you can find answer to questions like this faster by looking them up in Wikipedia...