[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>
wrote:
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
implementation?
Ted
- Re: Opportunistic STARTTLS in smtpmail.el, (continued)
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/05/30
- Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/05/30
- Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/05/30
- Re: Opportunistic STARTTLS in smtpmail.el, Robert Pluim, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el,
Ted Zlatanov <=
- Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/05/31
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/05/31
- client certs and CRL lists for GnuTLS (was: Opportunistic STARTTLS in smtpmail.el), Ted Zlatanov, 2011/05/03
- Re: client certs and CRL lists for GnuTLS, Lars Magne Ingebrigtsen, 2011/05/03
- Re: client certs and CRL lists for GnuTLS, Ted Zlatanov, 2011/05/03