3 ms·
The Google implementation of application specific passwords is horrible. There's nothing application specific about it -- it's valid for at least mail, calendar
by subway 8y ago
The Google implementation of application specific passwords is horrible. There's nothing application specific about it -- it's valid for at least mail, calendar, and contacts, with no way to limit the scope. It ends up being a password that effectively bypasses all MFA on your Google account. Where do you store such a password? That's a powerful credential to be regularly unlocking.
I should be able to create a credential that's valid for just SMTP, with no IMAP or cal/card access at all.
- Spivak 8y agoIf you want that level of granularity then you pretty much have to write an app but it's absolutely possible. https://developers.google.com/gmail/api/auth/scopes https://developers.google.com/gmail/api/auth/scopes
- subway 8y agoEven creating an app, the hoops are non-trivial. Due to the scope required (gmail.send), app verification and approval is required. I've been toying with writing a credential helper to obtain the oauth bearer token, but Authen::SASL::XOAUTH2 still needs to be written so that git-send-mail knows how to use it.
- epse 8y agoThat magic password is somewhat restricted as in you can only link an application with it once (which then should get an infinite token). It's mildly better. Last time I used it there were scoping options, but I might be mistaken
- subway 8y agoHuh? The magic password is the token. The "scoping" options are just a label (I suppose this might have recently changed), mostly targeting folks who are looking at using legacy mail/cal/card clients with only user/pass support, and are unsure what's going on. edit: Just triple checked -- the 16 character string returned when creating a "Calendar on iPhone" password works perfectly for SMTP via PLAIN over TLS.