[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 19:37:50 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Tue, 31 May 2011 22:32:47 +0200 Lars Magne Ingebrigtsen <address@hidden> 

LMI> Ted Zlatanov <address@hidden> writes:
>> 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.

LMI> I think it would be nice if it was as short as possible, too, because
LMI> this will be a blob of stuff in a file that people would be editing.

LMI> Which is why I kinda like the

LMI> secret gpg:<base 64> idea.

LMI> If we put all the secrets into the same blob, we can say stuff like

LMI> address@hidden@ssalt

LMI> that is, make the token names really short (one character), and use NUL
LMI> as the separator, so that we can put random other characters (including
LMI> space) into the passwords...

I understand.  But it sucks from the `auth-source-search' perspective
because now every secret blob has to be decoded to find out if it has
tokens X or Y when the search spec requires X or Y.  So I'm against it.

>From the user's perspective, it's no good either because looking at the
netrc file is not enough to tell what it contains, and this new format
can't be used by any other programs besides Emacs.  My format has the
nice property that it degrades into a normal netrc file gracefully.
It's trivial to write a bidirectional converter function, too.

(Just to be clear: my proposed format is
"login joe password gpg:ABCD123456" where the gpg: data decodes to
((data "mysecret") (salt "mysalt")) and no other values besides the
data are used outside; a gpg: value can only yield one piece of
data and only needs to be decoded when you need the actual data.)

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

LMI> Well, I'd hoped that you'd implement this.  :-)

I hope we will agree on the format.  I'll implement it when you give up
arguing with me ;)


reply via email to

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