Re: Opportunistic STARTTLS in smtpmail.el

[Ted Zlatanov]

On Thu, 02 Jun 2011 09:24:38 -0300 Stefan Monnier <address@hidden> wrote: 

SM> I'm not convinced it would be a good thing, but as long as we encourage
SM> users to use authinfo.gpg, then any code using auth-source.el will want
SM> to decide whether authentication is needed *before* calling auth-source
SM> since that call may prompt the user for a password.
SM> And if the code has to make that decision before calling auth-source,
SM> there's no real benefit to having field-encryption.

What you described does not require us to deprecate authinfo.gpg, only
demote it.  I think making it the second choice in the `auth-sources'
list, as I suggested, is sufficient, and will let users who have already
set it up keep using it without changing the default.

On Thu, 02 Jun 2011 20:45:40 +0900 Daiki Ueno <address@hidden> wrote: 

DU> That reminds me of Lars' post on the Gnus list:

DU> http://article.gmane.org/gmane.emacs.gnus.general/77172

DU> in the discussion:

DU> http://thread.gmane.org/gmane.emacs.gnus.general/77009/focus=77143

DU> where I suggested to have a separate file to store unencrypted
DU> information along with authinfo.gpg.  I can't remember what was the
DU> conclusion :)

The discussion petered out, and your proposal was .  I think my current
proposal is a continuation of
http://thread.gmane.org/gmane.emacs.gnus.general/77009/focus=77208 where
I propose something similar.  The key difference is Lars' idea of
encrypting only pieces of an otherwise unencrypted file.

On Thu, 02 Jun 2011 22:44:59 +0900 Daiki Ueno <address@hidden> wrote: 

DU> Ted Zlatanov <address@hidden> writes:

>> It will be less necessary as the first `auth-sources' choice, but still
>> useful, as Robert noted (I see case 2 as "encrypted tokens" since any
>> token can be encrypted in my proposal).

DU> Could you define the word "token"?  I have thought that it is an opaque
DU> value which connects unencrypted data to encrypted data.  However, it
DU> seems not.

In netrc files, tokens are any keys or values.  Unfortunately the word
is overused and confusing in our context.  Sorry.  I'll use "netrc field
encryption" from now on.

>> I'll simply make `auth-sources' ("~/.authinfo" "~/.authinfo.gpg")
>> 
>> which as a default will work fine.  Creation prompts will target the
>> first one.  The users can put insecure or token-encrypted data in the
>> first one and use the second one for more secure storage.

DU> Though I can't say anything without the detail of your proposal, I feel
DU> you are oversimplifying.

Why?  Have you tried it?  It will work immediately, without any code
changes.  The netrc field encryption is an add-on that doesn't affect
the general `auth-sources' and `auth-source-search' interaction.

DU> Anyway I will be happy if:

DU> - Gnus does not ask password when connecting to password-less services

It doesn't.  EPA/EPG may ask for a passphrase if `auth-sources' points
to a GPG-encrypted file, when and if `auth-source-search' hits that
file.  Usually :max 1 is specified for `auth-source-search' so it will
stop after the first match.  So, assuming my proposed change to
`auth-sources' above is installed, if ~/.authinfo is unencrypted
and the user puts parameters there, there should be no prompting at all
because `auth-source-search' won't hit ~/.authinfo.gpg.

DU> - Gnus does not store my passwords in plain text files by default

That's a personal preference.  It's inevitable, for instance, to use the
~/.netrc unencrypted file if you want libcurl to authenticate HTTP.  So
if you are forced into that situation (e.g. because you must use Git),
you may as well use ~/.netrc as an `auth-sources' entry.

The netrc field encryption will alleviate this problem but IMO it must
be at least the user's decision and we can't pick a default that will
make everyone happy.

DU> - Gnus can hide server or user names (or other attributes) if necessary

The netrc field encryption will work on any value, not just passwords.
You could even use it on keys, though that seems silly.

DU> Otherwise, no persistent password store is much better for me...

You could also use the Secrets API or propose a new `auth-sources'
backend that fits your needs (your expertise is greatly appreciated).  

I like the idea of a pure-data backend, for instance, where all the data
is in the `auth-sources' entry directly.  I would implement it if people
needed it, but it seems everyone prefers data formats they can share
with programs outside Emacs.

Ted