Re: Opportunistic STARTTLS in smtpmail.el

[Ted Zlatanov]

On Fri, 03 Jun 2011 00:03:18 +0900 Daiki Ueno <address@hidden> wrote: 

DU> Ted Zlatanov <address@hidden> writes:
>> The discussion petered out, and your proposal was .

DU> (was what?)

Sorry, I jumped ahead there.  Your proposal was not implemented.

>> 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.

DU> How those pieces of encrypted data can share the same passphrase?
DU> Otherwise a user will be asked passphrase every time when decrypting
DU> those pieces IIUC - that would be more painful than the current
DU> situation or the unencrypted file solution.

We'd associate a passphrase with the file, not each piece.  It should be
just like using a fully encrypted file, with the same passphrase caching
mechanism if symmetric encryption is used.

DU> Anyway I will be happy if:
>> 
DU> - Gnus does not ask password when connecting to password-less services
>> 
>> It doesn't.

DU> Why it doesn't?  Do you think the current behavior is reasonable enough?
DU> On my modern GNOME desktop environment, NetworkManager etc. do not asks
DU> passwords for password-less services.

EPA/EPG is actually the one asking for passphrases if an `auth-sources'
entry needs to be decrypted.  So I was just correcting the "Gnus" part,
not saying the behaviour is reasonable.  Partly, this thread is about
correcting the current behavior.

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

DU> Yes, I know, but are you using it daily?

Are you asking about the Secrets API backend?  I'm personally not able
to use it because I need my ~/.authinfo.gpg on several platforms.  But
it works: I've tested it and used it.  It doesn't support creation or
deletion yet.

>> 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.

DU> I don't understand what you are talking about - sounds like a sales talk
DU> by researchers in software engineering academia ;)

In the first sentence, I mean that `auth-sources' could look like this:

'((data ((:host "x" :user "y" :secret "z")))
  "~/.authinfo")

and then (auth-source-search :host "x" :user "y" :max 1)  would return
that first entry directly.  ~/.authinfo would not be examined.

The second sentence means that whenever I've proposed this, I seem to be
the only one that likes the idea.  So I haven't implemented it.  People
seem to like the netrc format because it's understood by other programs,
e.g. libcurl-based software like Git and curl.  But this idea seems to
me a good way to specify connection parameters and it could even support
the "gpg:<hex data>" format we are discussing for netrc field
encryption.

Ted