Better tools for kernel developers

Posted Feb 6, 2020 23:15 UTC (Thu) by dannyobrien (subscriber, #25583)
In reply to: Better tools for kernel developers by milesrout
Parent article: Better tools for kernel developers

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