Re: url library and GnuTLS, and Emacs-issued certificates

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 21 Mar 2011 17:33:33 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Mon, 21 Mar 2011 17:17:20 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 
CY> Ted Zlatanov <tzz@lifelogs.com> writes:
aj> so far there is no tls/ssl support for elpa.gnu.org . In my opinion
aj> this is a real problem as there is no way to check the authenticity
aj> and integrity of downloaded packages. Is it possible to expand the
aj> certificate of gnu.org to elpa.gnu.org?
aj> Of course this makes the package-manager not checking integrity -
aj> but I think anyone interested in doing so can modify it without
aj> problems.
>>> 
>>> I can install a certificate but it has to be requested by the domain
>>> owner so I'm not sure who to bug about it.

CY> Why not simply distribute the certificate file with Emacs?

TZ> I assumed we'd want https://elpa.gnu.org/packages/ to look reasonable in
TZ> a web browser.

TZ> In any case, I think it's a good idea to set up an Emacs Certificate
TZ> Authority (CA) so we can create certificates that Emacs will trust.  We
TZ> just need to ship the CA's certificate with Emacs then, not every
TZ> certificate it has signed.  We can then make a .p12 file that browser
TZ> users can import to trust Emacs-signed certificates.

TZ> It may make sense, though, to make this CA a facility for the whole GNU
TZ> project and then the Emacs CA can be an intermediate CA hanging off that
TZ> root CA.  That should be decided before we start pushing out
TZ> certificates, please, so we don't have to invalidate them later.

Any opinions on this?  It's really not hard to set up the CA stuff but
I'd like to know what people think before I do it.  It really seems like
it should be a GNU-level or FSF-level facility.

CY> Also, the Emacs package manager uses the url library for downloading via
CY> http.  How well does that library support https?  If I give
CY> `url-retrieve-synchronously' a https url, does it currently DTRT?

TZ> It's insecure currently and won't work on all platforms.  It uses tls.el
TZ> (see `url-https-create-secure-wrapper') which in turn relies on the
TZ> gnutls-cli or openssl binaries to be installed and usable, calling
TZ> gnutls-cli by default with --insecure (though the user can manually
TZ> adjust that, see `tls-checktrust').  We need the GnuTLS support at the C
TZ> level to make the url library secure through gnutls.el.  

TZ> I need to look at Claudio Bley's patch that was posted on emacs-devel 2
TZ> days ago and figure out what's wrong with hostname verification against
TZ> the certificate.  Once that's done we can promote gnutls.el+gnutls.c to
TZ> "need testing" and make them the default for the url library, Gnus, etc.

This work is almost done.  But probably a better approach than relying
directly on gnutls.el is to make url.el use proto-stream.el from Gnus,
which handles most of the connection details automatically whether Emacs
has GnuTLS support build-in or not.  I looked at it in order to make the
new GnuTLS support work properly and it seems like a good general
facility, not just for Gnus.

proto-stream.el doesn't depend on any Gnus internals, it's a standalone
library.  It could live in net/ in the Emacs repo.

Thanks
Ted