Re: GnuTLS for W32

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 6 Jan 2012 01:59:32 +0100 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> 2012/1/6 Ted Zlatanov <tzz@lifelogs.com>:
>> No, what I was proposing was a startup check that the "gnutls-critical"
>> package is up to date, meaning what the user has installed is the
>> latest on the GNU ELPA.

JB> At the end of the "gnutls-critical" chain, the intention is, either to
JB> update non-binaries (gnutls.c, gnutls.el), or binaries (the DLL).

The intention is to do whatever is appropriate on the platform to let
the user know they need to update and make the update easy.

>> The "gnutls-critical" package may do more afterwards, depending on the
>> OS.  On W32 it may trigger a patch eventually.  At first it will just
>> display a warning, as Chad suggested.

JB> And then, we're going to implement something similar for image
JB> libraries, because they can also have security-related bugs. Aren't
JB> we?

I'm not.  The risk is not worth the effort with image libraries.  The
risk outweighs the effort with GnuTLS, in my opinion.

>> I think the C glue to GnuTLS is an Emacs component, deeply embedded.
>> The point of an exploit is that it can cross the barrier between "not a
>> component/not our problem" and "oh crap."

JB> Lots of code in Emacs calls external tools (from grep to nslookup to
JB> make). Anyone of them could turn into an "oh crap" moment. But we
JB> don't feel the impulse to distribute grep and make sure it is up to
JB> date.

You're ignoring the "deeply embedded" part.  Obviously external
utilities are not able to compromise Emacs like internal C glue.  Can
you stick to comparable components like the libxml2 glue?

>> I believe `open-network-stream' can use GnuTLS for HTTPS connections,
>> which matters for a lot of cases, e.g. package.el.

JB> I disagree with "a lot of cases". There are a few Emacs components
JB> that connect to the network, but it is perfectly possible (and, I
JB> think, even common) not to need them on Windows.

If you don't think the package manager is important to our users, you've
got your head stuck in the sand.

>> I need the "gnutls-critical" startup check or some other way to tell the
>> user their GnuTLS version is at risk *by default*.

JB> s/need/want/.

I appreciate your attention to detail, but "need" is the verb I meant to
write there.

On Fri, 06 Jan 2012 04:15:28 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> The user doesn't know, usually, that there's been a critical GnuTLS
>> release that affects them.  Unlike normal updates, ignoring this can
>> actually compromise their security, not just corrupt or expose their
>> data.

LMI> $ ssh gnu.org
LMI> Checking for updates to ssh...  please wait
LMI> Apparently somebody has made a brute-force attack feasible against
LMI> the encryption algorithm ssh was going to use against the remote server.
LMI> Download and install a new version of ssh?

Are we talking GNU/Linux, where the package manager will handle this
update?  Or, say, Putty on W32, where such an auto-update makes more
sense (I don't know if Putty updates itself but that's not the point)?

SSH clients are not extensible layout engines with embedded interpreters
and flexible package managers.  As I keep saying, compare Emacs to
Firefox and Chrome, not to `vim' or `ssh' and `grep'.  It hasn't been
just an editor in a long while.  Eclipse is another good comparison
point.

But you raise an interesting point: even without client updates, the
server admin may disable the algorithm (manually or through a
sshd_config update), and the SSH protocol will try another algorithm as
configured on both sides.  And what if there's no algorithm they can
agree upon?  The connection fails mysteriously.  So yes, it matters to
the user sometimes that an algorithm has been compromised.

>> This is a crucial distinction.  So I want Emacs to notify the
>> user their GnuTLS is out of date, or else something else should
>> (e.g. the self-contained GnuTLS updater for W32 I proposed).

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

I just want a way to tell the users about it.  I don't care how we
deliver the update, if at all.  That should depend on the OS and as I
said should not be done by emacs-devel.

On Fri, 6 Jan 2012 05:11:47 +0100 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> If GnuTLS has a security issue, I wouldn't say that Emacs puts my
JB> machine at risk. GnuTLS does.

That's oversimplifying the problem, but yes, this is the fundamental
question.  I think, considering how Emacs is used and positioned as a
software package, we should take responsibility to notify the user on
the W32 platform and maybe on Mac OS X.  Probably not on GNU/Linux,
since we can assume on that platform the package manager's policies are
what the user wants, even if those policies put the user at risk.

This is my personal opinion.  You and Lars are clearly against that
approach.  I won't make any changes to Emacs in this direction until
either you're convinced otherwise, or the maintainers make a decision.

JB> Are you going to add a program to Emacs to test the hard drive for
JB> bad spots? That kind of checks (updates, I mean, not the disk test
JB> tool ;-) instill false security.

I was planning on that next.  How did you know?

JB> It's like the people who has an AV installed and thinks that it is
JB> protected because the AV software has not detected anything.

No, it's not like that at all.  Intrusion detection and security
advisories are completely different things.

Ted