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: Thu, 05 Jan 2012 08:50:10 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87ipkq6yy5.fsf@lifelogs.com> References: <87vcosskhc.fsf@wanadoo.es> <831urgr2yr.fsf@gnu.org> <87r4zgsh2w.fsf@wanadoo.es> <87ipks3zbo.fsf@uwakimon.sk.tsukuba.ac.jp> <87boqk3q69.fsf@uwakimon.sk.tsukuba.ac.jp> <87aa634st8.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwfvsgfv.fsf@wanadoo.es> <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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325771445 1665 80.91.229.12 (5 Jan 2012 13:50:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 13:50:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 05 14:50:40 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 1RiniK-0003Vb-0Q for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 14:50:40 +0100 Original-Received: from localhost ([::1]:57824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiniJ-0000Hp-JY for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 08:50:39 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiniC-0000Hh-6P for emacs-devel@gnu.org; Thu, 05 Jan 2012 08:50:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rini7-0005Bk-J3 for emacs-devel@gnu.org; Thu, 05 Jan 2012 08:50:32 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:37956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rini7-0005Bg-6D for emacs-devel@gnu.org; Thu, 05 Jan 2012 08:50:27 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rini3-0003Ms-WC for emacs-devel@gnu.org; Thu, 05 Jan 2012 14:50:24 +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 ; Thu, 05 Jan 2012 14:50:23 +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 ; Thu, 05 Jan 2012 14:50:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 90 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:Rb8jWVPe/ysl/CS9SzsvZiBzxEk= 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:147339 Archived-At: On Thu, 05 Jan 2012 00:36:57 -0500 Eli Zaretskii wrote: >> From: Ted Zlatanov >> >> I think, to get this working, we need a list of critical ELPA packages >> that Emacs will check for updates on startup and alert the user to >> upgrade. By default that list should be empty on all platforms, except >> on W32 it will contain the "gnutls-w32" package. EZ> Again, why are we treating MS-Windows specially? Why shouldn't Emacs EZ> issue the same alert on GNU and Unix systems, if GnuTLS is found to be EZ> unavailable? The fact that several distributions have Emacs depend on EZ> GnuTLS does not mean all of them do or will, and let's not forget that EZ> even in the year 2012 users can build their own Emacs (without EZ> GnuTLS). You're right. Do you agree with the general idea of checking for critical updates on startup, though? I would actually also like to bundle trusted certificates. The Diginotar compromise showed the need for managing the certs proactively, and we can't rely on what's on W32 systems. On other platforms we can let the distribution choose the right cert bundle. Right now, gnutls.el will take a list of trustfiles or default to /etc/ssl/certs/ca-certificates.crt, which is hardly ideal for all platforms. On Thu, 5 Jan 2012 03:36:38 +0100 Juanma Barranquero wrote: JB> The moment the packages are accesible from the official site, there's JB> certain responsibilities. For example, to issue security upgrades as JB> fast as possible. ... JB> Responsibility and obligation are disjoint concepts. I don't mind the JB> load, but I hate accepting (not personally, but as a project) the JB> responsibility to do things, like compiling GnuTLS binaries and JB> distributing them, that are utterly disconnected from Emacs JB> development per se. The moment we do that, people will expect we also JB> provide up-to-date binaries for image libs, libxml2, d-bus, you name JB> it. I think the risk of providing out-of-date libxml2 or libxpm is much smaller than providing out-of-date GnuTLS. So while I understand your concern about this slippery slope, I think we can resist it, and regular releases can address the general need for updates. On Thu, 05 Jan 2012 00:24:56 -0500 Eli Zaretskii wrote: >> From: Ted Zlatanov >> I'm concerned about GnuTLS updates after the install. An ELPA package >> could do that, a simple DLL drop couldn't. EZ> That's true, but if we assume that an urgent need to upgrade GnuTLS EZ> will not be too frequent, we can update it with each release and in EZ> binaries of development snapshots. That would probably do 80% of the EZ> job, if not more. Unfortunately security issues and their fixes are inherently urgent and unpredictable (e.g. the Diginotar compromise). Note above about my desire to also provide cert bundles in this package, so it could do much more than a DLL drop. But if we go with Joakim's full installer idea, that would do the job better than package.el could. On Thu, 05 Jan 2012 06:40:27 +0100 joakim@verona.se wrote: j> If I were to do this I would make a build bot that produced daily j> binaries of the installer of a complete Emacs installation including the j> dll files. I would not bother with partial updating of particular dll:s j> at this time. If we tell the user to reinstall because GnuTLS is out of date, would that be a big burden? I guess that's a fourth option for distributing and updating GnuTLS, which could be combined with the ELPA package for notifications: 1) zipfile drop 2) ELPA package in the GNU ELPA archive with startup GnuTLS version check 3) GnuTLS standalone installer+updater 4) Emacs installer+updater Combining (4) and (2) seems most convenient for the users: they will have a single installer for all of Emacs (a convenience that goes beyond this thread), and they'll get notified on all platforms when GnuTLS is out of date. Ted