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

[Chong Yidong]

Ted Zlatanov <address@hidden> writes:

> TZ> In any case, I think it's a good idea to set up an Emacs
> TZ> Certificate Authority (CA) so we can create certificates that
> TZ> Emacs will trust...  It may make sense, though, to make this CA a
> TZ> facility for the whole GNU project and then the Emacs CA can be an
> TZ> intermediate CA hanging off that root CA.  That should be decided
> TZ> before we start pushing out certificates, please, so we don't have
> TZ> 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.

I don't think setting up a GNU-wide CA is a good idea; it's mission
creep and the gains seem negligible.  As for an Emacs-specific CA, I
don't know enough of the details of how CAs are maintained to evaluate
the proposal.

On reflection, the best solution is the one that needs the least work
from us.  So it's probably best to ask the FSF sysadmins to request and
install a cert, as you originally suggested.  Could you email them?

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

How bout merging the open-protocol-stream code directly into
open-network-stream?  Then we can make open-protocol-stream an alias for
open-network-stream, and (provide 'proto-stream) in subr.el.

If the Gnus developers don't object, I propose to do this.

(Also, gnutls.el should be changed to explicitly recommend that
applications not use it directly, and we should merge net/tls.el and
gnus/starttls.el; those two packages appear to be duplicates.)