Re: secure plist store

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 29 Jun 2011 20:30:34 +0900 Daiki Ueno <ueno@unixuser.org> wrote: 

DU> Ted Zlatanov <tzz@lifelogs.com> writes:
DU> Not really - GPG2 passphrase caching is smarter than elisp level caching
DU> as it uses unique ID embedded in GPG data, so it allows user to share
DU> passphrases even among multiple Emacs processes.
>> 
>> ...so you're saying we don't benefit from a feature we can't use?  What
>> are we supposed to change or improve?

DU> OK, honestly, I would say that it won't work with GPG2 since GPG2 does
DU> always do the password operation in the agent.  Have you tried that?

I'm not sure what you're asking, unfortunately.  What do you want me to try?

>> The nicest thing about the netrc format, IMHO, is that other programs
>> understand it.

DU> What other programs use GPG encrypted netrc?

You mean fully encrypted (authinfo.gpg)?  None; that format, however, is
the only one available that offers full encryption.  The field
encryption (GPG tokens) is backwards compatible and no other programs
support decrypting those tokens yet (although I would push for it in
libcurl, for example).

DU> What other programs writes passwords automatically into that file?

Why does that matter?  It's a convenience we offer.  Most other programs
that use it fail silently if the credentials are not in there; we ask to
save instead.  That seems a good choice to me but I want to listen and
change things if there are better ways to do it.  So far Stefan Monnier
and you have complained about the *prompting* and I've tried to fix the
prompting issues that Stefan noted in a long bug thread.  But no one has
complained about the *functionality* or asked to change it.

DU> IMHO, these are very ad-hoc approaches and causing unnecessary
DU> complexities.

Perhaps you could recommend a better way.  Besides the Secrets API,
which does not work across platforms, I'm not aware of one.

>> Editing the netrc directly is not a power user feature.  They are very
>> easy to read and understand.  I have shown dozens of people with various
>> skill levels how to use them and the only question they tend to ask is
>> "what about spaces in the password?"

DU> I guess that file is edited when a user is accessing to some machines
DU> frequently with legacy clients (like ~/.rhosts).

Git+libcurl use the netrc file, for instance.  It's the only way to
provide passwords for Git over HTTP AFAIK.

DU> I really hope that Gnus does the password caching in more suckless
DU> way, as modern clients like Thunderbird do, at least by default.

What are you talking about when you say "password caching"?  There are
at least 3 pieces:

- searching for credentials and using them (host, port, user name, secret)

- saving credentials for the session

- saving credentials permanently

Not to mention the EPA/EPG interaction with the .gpg files, where it
sometimes needs to ask for the passphrase.

DU> For my case, I have never edited netrc by hand.  After upgrading to Gnus
DU> in Emacs 24, it started asking with confusing multiple-choice question
DU> to save the password, and I answered the question with "y" without
DU> reading the help carefully.  Then, from the next time, it started asking
DU> passwords unwanted timing - really annoying, and it shouldn't be the
DU> default behavior for new users.

I'm trying to understand the problem of "unwanted timing."  Do you mean
you're getting prompted for your credentials repeatedly?  What Gnus
backend are you talking about?  Set `auth-source-debug' to 'trivia and
check the *Messages* buffer to see what `auth-source-search' calls are
failing; that's a good first step to understand what's wrong.

In general, if you don't think we should be asking for passwords, how
would you suggest we behave when passwords are needed, e.g. for IMAP?
Would you rather see something like assistant.el employed to do a
multi-step configuration, and then when credentials are missing we
simply say "sorry but you have to redo the setup for service X" or ask
for the credentials immediately?  I think that's what most other MUAs
do, with some small variations.  They usually save the credentials to a
place that only works for that MUA.

Ted