Subject: Re: bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg

From: Ted Zlatanov <[email-masked]>
Date: Fri, 27 Jan 2012 10:23:20 -0600

On Fri, 27 Jan 2012 10:47:32 +0900 Daiki Ueno <[email-masked]> wrote: 

DU> Ted Zlatanov <[email-masked]> writes:
>>>>> 2) use unencrypted authinfo with encrypted password tokens, which
>>>>> looks like this:
>>>> 
>>>>> machine supertest password
>>>>> gpg:jA0EAwMC2tUEaZgM7A5gyWM/owySdCOS/cjoFCuf8LI1d1kYX7z6cjsNkakM04u1geh/iesqyH3XQFI+SEVLb/oEC/EoQ0LIgRRoBiLyu9XZWN1ytY7MQxpPZniFz13oGV4/Dwl8yrP3Hba5LfQpHy2FZRM=
>> 
>> It works fairly well but it's hacky, and can't be shared with other
>> programs.  I'd like to implement it with libnettle at least, so it
>> doesn't depend on the external gpg utility.  But yes, we could do this
>> one and it would work on all platforms with libnettle.

DU> I remember there were a couple of concerns:

DU> (1) it also doesn't work with GnuPG2 at all (have you tested it?)

No, I haven't tested it.

DU> (2) even with libnettle, you need to implement OpenPGP packet handling
DU>     if you want to keep the data compatibility with GPG (I don't think
DU>     it is a good idea to reinvent another encrypted data format with
DU>     plist as you proposed)

Perhaps it would be OK to generate OpenPGP packets using libnettle, so
we are compatible with GPG.  That would be a decent amount of work but
it would suddenly remove Emacs's dependency on an external utility and
make it work on all platforms with GnuTLS support.  I think that's a
really good direction now that we have libnettle!  Are you interested in
working on it with me, and do you see any potential problems with this
approach?

DU> How about:

DU> (1) add M-x auth-source-save command to save passwords manually
DU> (2) (message "Type \\[auth-source-save] to save your passwords to file")
DU>     instead of the question

That's a very good suggestion, since currently the saving functionality
is done as a closure we pass back (internally this closure opens the
file, adds the line, then closes it, so it doesn't care about the
contents and thus is safe to call in any order).  So we could simply
queue those closures and then call something to save them.  But all the
prompting and UI has to be redesigned so it would be a lot of work for
me.  I'd like some more opinions on this.

On Thu, 26 Jan 2012 16:41:19 -0500 Stefan Monnier <[email-masked]> wrote: 

>> I'd like to implement it with libnettle at least, so it doesn't depend
>> on the external gpg utility.

SM> But that would make it work even less with other programs.

Yes.  I like Ueno-san's suggestion of generating OpenPGP packets
ourselves.  We can let the user decide whether he prefers encrypted
password tokens, encrypting the whole file, or leaving it in the clear.
Maybe we could even talk to the GPG agent for credentials.

SM> Another option (the better long-term option) is to use an external
SM> keychain service to handle these issues.  That's what we should focus on
SM> for the "next time".
>> Do you mean gpg-agent or the OS keychain?

SM> I mean the keychain.

>> Neither is available on all platforms consistently.

SM> AFAIK all platforms have a keychain nowadays and it's the best place to
SM> put sensitive passwords such as the ones used to access your IMAP server.

I don't think GNU/Linux has anything beyond the Secrets API, and that
depends on many optional components.

Mac OS X has a standard keychain, which someone attempted to support in
Emacs but didn't get it finished.  It's not too complicated.

W32 has some functionality (see
http://msdn.microsoft.com/en-us/library/aa380261(v=VS.85).aspx and
http://stackoverflow.com/questions/442923/windows-equivalent-of-os-x-keychain_
for some discussion) but not a fully capable keychain.

I don't know about the other platforms we support, but I hope this shows
that we should support but not rely on OS keychains.  `auth-sources'
reflects that by making them optional choices but not the defaults.

>>>> IIRC for 23 the default was to keep the password for the current session
>>>> and not to store it in any file at all.  I think it's a better default
>>>> than writing it in clear in some file, so at least for 24.1 reverting to
>>>> the Emacs-23 default is very attractive.
LI> Well, Emacs 23 just made you write the .authinfo file by hand.  Emacs 24
LI> prompts you for whether you want to store the password or not.  If you
LI> don't want to, say "n".

SM> Yes, I guess it's good enough.

>> One possible flow:
>> If the user says `y' then we can ask (if `auth-sources' is 'ask) 
>> "Do you want to keep your passwords in a GPG-encrypted file?"

>> If they say `y' then set `auth-sources' to "~/.authinfo.gpg" and check
>> that EPA/EPG are enabled. If GPG is not available, what do we do? Use
>> libnettle? Or explain and pretend they said `n'?

SM> If GPG is not available, ask a different question, as in "It will be
SM> saved in cleartext, is that OK?"

I think we'll need something on top of EPA/EPG if we support OpenPGP
packets with libnettle, an encryption services wrapper, which we can ask
"can we encrypt?" "can we encrypt a file with external GPG?" "can we
encrypt a file with internal OpenPGP and libnettle?" and so on.  Once we
have that wrapper API we can build the user interaction easily, without
ad-hoc checks.

This is getting a little long for the bug report, do you want to move it
to emacs-devel?

Ted