Gnus development mailing list
 help / color / mirror / Atom feed
From: Lars Magne Ingebrigtsen <larsi@gnus.org>
To: ding@gnus.org
Cc: emacs-devel@gnu.org
Subject: Re: gnutls status
Date: Fri, 26 Nov 2010 15:10:39 +0100	[thread overview]
Message-ID: <m3bp5cdvkw.fsf@quimbies.gnus.org> (raw)
In-Reply-To: <87ipzkmgfn.fsf@lifelogs.com>

Ted Zlatanov <tzz@lifelogs.com> writes:

> So we'd need to either 1) require 2.10.x, or 2) complicate the C code
> and API using just 2.8.x features and maybe figure out how to set up our
> own callback mechanism, or 3) use the 2.10.x features only when it's
> available, using autoconf detection, which is twice as complicated as
> (2).

Is 2.10.x at least backwards-compatible, so that if we do implement the
complicated 2.8.x features, it'll continue to work in the future, too?

> I think every package should explicitly choose to support gnutls.el, it
> shouldn't be an Emacs-wide choice.  There's too many configuration
> options that depend on the purpose.  For instance IMAP and HTTPS have
> really different security needs.

True.  On the other hand, look at `nnimap-open-connection' and weep.  It
started off as a simple function and grew into a monster.  That's why I
haven't adapted nntp/pop3/etc to use gnutls yet -- I don't want to have
to repeat the same code all over the place.

And the STARTTLS situation, in particular, is a nightmare, since the
sane gnutls way of doing it and the really awkward starttls.el way of
doing it require different code paths.

And we're going to have to support gnutls/tls.el/starttls.el in all the
connections for the unforeseeable future.  I kinda want to write a new
connection framework that'll just separate out all this cruft into a
separate package, but I can't really see a sensible unified interface.
Especially with the STARTTLS stuff.

I mean, ideally, in the future whenever you do a
pop3/imap/nntp/smtp/etc connection, Emacs should opportunistically
switch on STARTTLS if the server supports it.  Encryption is good.
Switching on STARTTLS is virtually free if you have gnutls.  It's really
expensive if you don't.  I mean, time-wise for the user.

But I don't really see an easy way to do that.  You'd need
protocol-specific callbacks and stuff.  And I hate frameworks.  And
it'll be brittle, anyway, since starttls.el is kinda brittle.

But I do think we need some kinda of compat library to avoid going
totally insane.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen




  parent reply	other threads:[~2010-11-26 14:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 17:29 Julien Danjou
2010-11-26  0:28 ` Lars Magne Ingebrigtsen
2010-11-26 12:13   ` Ted Zlatanov
2010-11-26 12:51     ` Julien Danjou
2010-11-26 15:02       ` Stefan Monnier
2010-11-26 15:56         ` Julien Danjou
2010-11-26 18:42           ` Stefan Monnier
2010-11-27  9:36             ` Julien Danjou
2010-11-27 14:28               ` Stefan Monnier
2010-11-28  9:55               ` Lars Magne Ingebrigtsen
2010-11-26 14:10     ` Lars Magne Ingebrigtsen [this message]
2010-11-27 14:18       ` Lars Magne Ingebrigtsen
2010-11-27 14:40         ` Lars Magne Ingebrigtsen
2010-11-27 15:31           ` Lars Magne Ingebrigtsen
2010-11-27 16:04             ` Lars Magne Ingebrigtsen
2010-11-27 16:37               ` Steinar Bang
2010-11-27 16:41                 ` Lars Magne Ingebrigtsen
2010-11-27 16:59                   ` Lars Magne Ingebrigtsen
2010-11-27 17:33                     ` Dan Christensen
2010-11-27 17:36                       ` Lars Magne Ingebrigtsen
2010-11-27 17:42                         ` Lars Magne Ingebrigtsen
2010-11-28  2:36             ` Automatic STARTTLS upgrades (was: gnutls status) Lars Magne Ingebrigtsen
2010-11-28 12:28               ` Automatic STARTTLS upgrades Lars Magne Ingebrigtsen
2010-11-28 13:34                 ` Lars Magne Ingebrigtsen
2010-12-14 22:59       ` gnutls status Ted Zlatanov
2011-03-01 21:52         ` Ted Zlatanov
2011-03-05 11:01           ` Lars Magne Ingebrigtsen
2011-03-05 14:46             ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bp5cdvkw.fsf@quimbies.gnus.org \
    --to=larsi@gnus.org \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).