From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Thu, 05 Jan 2012 16:08:46 +0100 Message-ID: References: <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> <87ipkq6yy5.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325776169 5646 80.91.229.12 (5 Jan 2012 15:09:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 15:09:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 05 16:09:25 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 1RiowW-0005Ta-JV for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 16:09:24 +0100 Original-Received: from localhost ([::1]:36633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiowW-0001qu-3b for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 10:09:24 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:50298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiowO-0001q5-2a for emacs-devel@gnu.org; Thu, 05 Jan 2012 10:09:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiowM-000428-4U for emacs-devel@gnu.org; Thu, 05 Jan 2012 10:09:16 -0500 Original-Received: from mx1.bahnhof.se ([213.80.101.11]:61448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiowL-000418-HI for emacs-devel@gnu.org; Thu, 05 Jan 2012 10:09:14 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx1-reinject (Postfix) with ESMTP id AC1172958D8 for ; Thu, 5 Jan 2012 16:09:06 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF1) Original-Received: from mf1.bahnhof.se ([127.0.0.1]) by localhost (mf1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i44leSLkld4S for ; Thu, 5 Jan 2012 16:09:02 +0100 (CET) Original-Received: from exodia.localdomain (h-235-102.a149.priv.bahnhof.se [85.24.235.102]) by mf1.bahnhof.se (Postfix) with ESMTP id AA035AEA875 for ; Thu, 5 Jan 2012 16:09:02 +0100 (CET) Original-Received: from chopper.vpn.verona.se (unknown [192.168.201.14]) by exodia.localdomain (Postfix) with ESMTP id 309F74E00A4 for ; Thu, 5 Jan 2012 16:08:49 +0100 (CET) In-Reply-To: <87ipkq6yy5.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 05 Jan 2012 08:50:10 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: FreeBSD 6.x (1) X-Received-From: 213.80.101.11 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:147345 Archived-At: Ted Zlatanov writes: > 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. I think using a patcher should be sufficient: http://wiz0u.free.fr/prog/WPatch/ That way we get a one stop solution for all changes. Surely there must be an existing nsis installer for Emacs somewhere? If there isn't I can provide a skeleton for someone else to tweak. Emacs ought to be fairly easy to make an installer for since you basically just copy the binaries somewhere and run out of tree. (I suppose, I'm not familiar with how people run Emacs on Windows these days) BTW the Nsis compiler can run on Gnu/Linux using Wine. There is a native version as well but I never got it working properly. Also you will be surprised at how arcane the Nsis language is(partly an artefact of the domain), so one is often tempted to use something else. Last time I checked the alternatives were worse, but that might have changed. > Ted > -- Joakim Verona