Hacker News Reader

Comment by sevensor | Hacker News Reader

One thing a lot of email providers (at least gmail and fastmail) do is let you create application passwords that you can use for specific purposes. So if you're at all queasy about having your password in plain text on the hard drive, you can create a special password just for git.

Edit: you don't have to set up a terminal email client at this point, but if you figure out how to use git-send-email, you're just inches away from using mutt.

View on HN

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.

If 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

Even 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.

That 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

Huh?

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.

I haven't set this up, but looking at the manpages, it seems you can set git to obtain the password from your password manager (which should keep your password encrypted). From gitcredentials(7):

> Without any credential helpers defined, Git will try the following strategies to ask the user for usernames and passwords:

> 1. If the GIT_ASKPASS environment variable is set, the program specified by the variable is invoked. A suitable prompt is provided to the program on the command line, and the user’s input is read from its standard output.

> 2. Otherwise, if the core.askPass configuration variable is set, its value is used as above.

> 3. Otherwise, if the SSH_ASKPASS environment variable is set, its value is used as above.

> 4. Otherwise, the user is prompted on the terminal.

So, for example, if you're using `pass`, the password-store, you can just set one of these to `pass smtp/me@example.com`, and pass will prompt you for your decryption password for your smtp password.

> having your password in plain text on the hard drive

That's not necessary for git. git has a facility called git credential that can allow it to cache the password (or other piece of information) for a given period of time[1]. So, when you use git send-email, it will prompt you for the the password.

[1] https://git-scm.com/docs/git-credential-cache

You can also omit it and type it in each time you use git send-email, or you can set it up with your on-site keyring using git-credential:

https://git-scm.com/docs/gitcredentials

Ah, that's quite nice. I like the ability to strike your own balance between convenience and paranoia afforded by git-credential-cache.

They're getting closer to public-key authentication, I guess that's good.

Ooooooo.

Is there such a thing as SSMTP/SIMAP (i.e. something that is to SMTP/IMAP as SFTP is to FTP - i.e. an SSH-based thing that sends and/or receives mail to/from a mail server)? It'd be badass to be able to literally just use my SSH keys to authenticate when sending/receiving mail.

I'm using a setup similar to the described one, though without SMTP or IMAP: a MUA is set to use `ssh <host> sendmail` instead of a local sendmail, and `doveadm sync sh -c ... "ssh <host> doveadm dsync-server"` for retrieval/synchronization. It's indeed nice and handy.

Edit: My setup with mu4e is described in more detail at https://defanor.uberspace.net/notes/email.xhtml

You can literally invoke imapd over ssh and it will preauthenticate as the user that invoked imapd. I used to do this with PINE 20 years ago. Good luck getting any of the big MSPs to support it, though.

I used elm back in the day. Was excited and confused when I started seeing all sorts of articles about elm, until I realized it was a different elm.

I'll have to give that a whirl. This would be with my own mailserver, so whether or not the MSPs support it is irrelevant :)

That does sound perfect. Don't know if it exists.

Reply on news.ycombinator.com