[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opportunistic STARTTLS in smtpmail.el

From: Ted Zlatanov
Subject: Re: Opportunistic STARTTLS in smtpmail.el
Date: Tue, 31 May 2011 14:39:54 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Tue, 31 May 2011 20:19:54 +0200 Lars Magne Ingebrigtsen <address@hidden> 

LMI> Ted Zlatanov <address@hidden> writes:
>> s/auth-info/auth-source/g right?

LMI> Yes.  :-)

>> IOW rather than your "secret" token, let's keep the existing tokens but
>> the netrc backend of auth-source will know that when it sees "xyz
>> gpg:<hex data>" it needs to decode that hex data.

LMI> I don't know how gpg works here.  Does gpg-encrypting the same string
LMI> give you identical results, or does gpg auto-salt things?  The idea with
LMI> putting several tokens into the secret part was to 1) make it more
LMI> difficult to brute-force, and 2) make it possible to salt the string, so
LMI> that if you have two services with the same user-name/password, the
LMI> secret tokens would not be identical.

That's all fine, we can still auto-salt and bundle random data in the
binary.  The gpg:<hex data> format should be an alist with 'data as
the key we want; any other keys can be ignored.  But it's important to
support it everywhere, not just for passwords.

I propose the hex data be the alist printed in the UTF-8 encoding, then
converted to the unibyte conversion, encrypted, and hex-encoded.  The
next non-hex character (usually space or newline) ends the data.  If we
fail to decode it, we print a warning message.

>> We should provide a general mode that can show the file with all the
>> gpg:<hex data> locations replaced, showing the decrypted data with text
>> overlays and different colors.  The mode could also edit the encrypted
>> data inline.  This would be very useful for all of Emacs, not just
>> auth-source.  Sort of a scratch pad with arbitrary encryption intervals.
>> With such a mode, a lot less direct auth-source support will be needed
>> for these encrypted tokens.  The netrc backend would simply use the
>> general mode.

LMI> Sounds way too complicated, I think.  The usage at hand is the netrc
LMI> file format, and I don't think it would have much utility beyond that.

I disagree about the utility, but...

LMI> Besides, adding this to netrc would be really trivial.  Making it
LMI> general would be difficult.

I agree about this.  For your purpose, let's get the gpg tokens working.
Then we can overengineer the general solution into a minor mode, an
EmacsWiki page, and a long discussion about the aesthetics of hex data.

What do you need from me to get the above done, if you agree about the


reply via email to

[Prev in Thread] Current Thread [Next in Thread]