emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GnuTLS for W32


From: Ted Zlatanov
Subject: Re: GnuTLS for W32
Date: Sat, 07 Jan 2012 08:28:11 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

On Sat, 07 Jan 2012 18:24:39 +0800 Chong Yidong <address@hidden> wrote: 

CY> - First of all, any change involving distributing GnuTLS with Emacs
CY>   should be post-24.1.

OK; see below.

CY> - Phoning home on startup by default is out of the question.  There are
CY>   lots of users with the "open Emacs many times" usage pattern, even
CY>   though that usage pattern is discouraged.  Accessing the network for
CY>   each startup would be unreasonable, quite apart from the privacy
CY>   concerns (GNU knows each time you launch Emacs!)

CY> - I am open to improvements to package.el to implement _periodic_ update
CY>   checking, and improvements to check for updates in M-x list-packages.
CY>   It is probably not too difficult to add some infrastructure to
CY>   highlight "strongly recommended updates" in the Package Menu.

OK.  How about a new variable `package-critical-packages' which is empty
by default?  When it has elements, Emacs will check on startup if those
packages have been updated, and after the 24.1 release we can add
highlighting to the package list, plus some UI to add/remove packages to
the critical list.  I would really like to get the basic functionality,
off by default, into 24.1.  I think the risk is minimal and the benefit
to users is significant.  The UI will also be simpler, just y/n to the
update (no need for the "never bother me about this again" choice),
since we know that any packages in the critical list were added by the
user.

I think periodic checks won't work well in the Emacs world, but perhaps
I am misunderstanding what you mean.

CY> - I agree with Lars' point that

>> I don't really see that there's much of a difference between bugs in
>> libgnutls and in the Emacs binary proper.  If a major security hole was
>> discovered in Emacs, then presumably a new Emacs release would be made.
>> If a major libgnutls hole was discovered, then presumably someone would
>> zip up a new Windows release.

CY>   If a really serious security flaw is found in GnuPG, and we are
CY>   distributing GnuPG with Emacs, we should make an Emacs security
CY>   release, exactly as though it was a security flaw in Emacs itself.

OK.  Since the consensus seems to be that the platform-specific
installer's maintainers, not emacs-devel, should deal with installing
GnuTLS and other third-party libraries, the responsibility for such
security releases should be with the installer's maintainers, and each
platform will have to figure out its own way to notify the user that
there's a critical security update.

If you agree, this work doesn't have to wait for the 24.1 release since
it won't require changes to Emacs.  For a W32 installer I can work with
Joakim.  For Mac OS X I don't know if the NS port, when bundled as an
app, can include its own GnuTLS and other libraries, or if we'll require
a real installer.  On both those platforms self-updating should be
possible.  Does all of that make sense?

Ted




reply via email to

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