4 ms·

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'r

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.

Sir_Cmpwn 8y ago
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 https://git-scm.com/docs/gitcredentials
- sevensor 8y ago
  Ah, that's quite nice. I like the ability to strike your own balance between convenience and paranoia afforded by git-credential-cache.
bo1024 8y ago
They're getting closer to public-key authentication, I guess that's good.
- yellowapple 8y ago
  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.
  - bo1024 8y ago
    That does sound perfect. Don't know if it exists.
  - defanor 8y ago
    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 https://defanor.uberspace.net/notes/email.xhtml
  - hallgnop 8y ago
    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.
    - sevensor 8y ago
      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.
    - yellowapple 8y ago
      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 :)
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 ago
  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 https://developers.google.com/gmail/api/auth/scopes
  - subway 8y ago
    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.
- epse 8y ago
  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
  - subway 8y ago
    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.
jolmg 8y ago
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.
u801e 8y ago
> 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 https://git-scm.com/docs/git-credential-cache

Sir_Cmpwn 8y ago

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 https://git-scm.com/docs/gitcredentials

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

bo1024 8y ago

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

yellowapple 8y ago
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.
- bo1024 8y ago
  That does sound perfect. Don't know if it exists.
- defanor 8y ago
  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 https://defanor.uberspace.net/notes/email.xhtml
- hallgnop 8y ago
  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.
  - sevensor 8y ago
    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.
  - yellowapple 8y ago
    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 :)

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 ago
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 https://developers.google.com/gmail/api/auth/scopes
- subway 8y ago
  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.
epse 8y ago
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
- subway 8y ago
  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.

jolmg 8y ago

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.

u801e 8y ago

> 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 https://git-scm.com/docs/git-credential-cache