From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Fri, 06 Jan 2012 09:08:54 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y5tkzzwp.fsf@lifelogs.com> References: <877h17scdo.fsf@wanadoo.es> <87hb0b77nr.fsf@lifelogs.com> <8739bvs27m.fsf@wanadoo.es> <87ty4b4329.fsf@lifelogs.com> <87hb0b3yoe.fsf@lifelogs.com> <6ED011D5-E185-44C6-BB31-A445A4E5F83A@gmail.com> <87wr976otx.fsf@lifelogs.com> <87ipkq6yy5.fsf@lifelogs.com> <87boqi6tzz.fsf@linux-hvfx.site> <87ehve3ul8.fsf@lifelogs.com> <87lipl22xm.fsf@lifelogs.com> <87boqh20ha.fsf@lifelogs.com> <877h151x01.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325858969 29451 80.91.229.12 (6 Jan 2012 14:09:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 14:09:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 06 15:09:24 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjATz-0002wp-5x for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2012 15:09:23 +0100 Original-Received: from localhost ([::1]:55878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjATy-00053L-Kk for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2012 09:09:22 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjATt-00053G-1M for emacs-devel@gnu.org; Fri, 06 Jan 2012 09:09:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjATm-00037g-L1 for emacs-devel@gnu.org; Fri, 06 Jan 2012 09:09:17 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:40684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjATm-00037T-Ap for emacs-devel@gnu.org; Fri, 06 Jan 2012 09:09:10 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RjATk-0002r4-Sh for emacs-devel@gnu.org; Fri, 06 Jan 2012 15:09:08 +0100 Original-Received: from c-76-28-40-19.hsd1.vt.comcast.net ([76.28.40.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2012 15:09:08 +0100 Original-Received: from tzz by c-76-28-40-19.hsd1.vt.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2012 15:09:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 130 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-40-19.hsd1.vt.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Cancel-Lock: sha1:LWVjKEpuTUdJZUcASESqkQbz1X8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147397 Archived-At: On Fri, 6 Jan 2012 01:59:32 +0100 Juanma Barranquero wrote: JB> 2012/1/6 Ted Zlatanov : >> 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 wrote: LMI> Ted Zlatanov 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 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