Re: more on starttls, gnutls-cli and using tls for mail

[Karl Fogel]

Roland Winkler <address@hidden> writes:
>> I've been thinking that lately too. 
>>
>> First, the fact that .authinfo is created world-readable just seems
>> like a clear bug.  Also easy to fix (sorry, I don't have patch, but
>> I could come up with one if we all agree this is a straight bug). 
>
>See bug #9113. So yes, I agree that this is a bug.   See also bug
>#7487 where some issues related to .authinfo were discussed: Under
>certain circumstances Gnus needed to repeatedly decrypt
>~/.authinfo.gpg, which requires the gpg passphrase. Yet I do not find it
>justified to make an unencrypted ~/.authinfo the default because of such
>a nuisance. If at all, I believe it should be the other way round: the
>default should be ~/.authinfo.gpg. If someone doesn't like that for
>whatever reason, he or she can change that in the init file.

Bug #9113 is slightly different from what T.V. and I were saying.  #9113
suggests solving the exposure problem through encryption, and then #7487
has a long discussion about what kind of encryption it should be --
public key or symmetric -- how the user interface should work, etc.

But I think T.V. and I are just saying: "In the plaintext case, let's at
least make the file non-world-readable!"

Offering encryption is great, but it's also very complex and error-prone
(as the bug reports show).  There will always be a plaintext case, since
users cannot be required to have GPG-like software installed.  In the
plaintext case, we could behave better than we do.

But it sounds like we probably agree on this too, and I should just make
the change :-).

Separately, I think it's bad that we removed the Elisp-based API for
passing this authn information, since some people (like me) are already
using Elisp to fetch the auth creds securely from elsewhere, and having
to dynamically construct a ~/.authinfo file as a means of passing that
information *to other Elisp* is, shall we say, a really poor API.

There's no reason we can't have both `smtpmail-auth-credentials' and
~/.authinfo (or ~/.authinfo.foo), and simply fall try the former when
the latter is unavailable.

However, that's a larger change, or semi-reversion.  I don't know if it
would be accepted; I guess it belongs in a distinct thread.

-K