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: Tue, 03 Jan 2012 10:00:15 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <871urgal1c.fsf@lifelogs.com> References: <87ty4fbje8.fsf@lifelogs.com> <83ehvjs8t5.fsf@gnu.org> <87pqf3bcom.fsf@lifelogs.com> <83boqns68o.fsf@gnu.org> <87liprazr1.fsf@lifelogs.com> <83wr9bqez3.fsf@gnu.org> <87y5tr9dwv.fsf_-_@lifelogs.com> <87k45alwgb.fsf@wanadoo.es> <87fwfyltm1.fsf@wanadoo.es> <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> <87ipktag2e.fsf@lifelogs.com> <87aa659bpw.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 1325602874 32156 80.91.229.12 (3 Jan 2012 15:01:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2012 15:01:14 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 16:01:10 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 1Ri5rP-0004jl-O9 for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 16:01:08 +0100 Original-Received: from localhost ([::1]:55321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri5rP-0005IZ-DT for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 10:01:07 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri5rI-0005IG-GE for emacs-devel@gnu.org; Tue, 03 Jan 2012 10:01:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ri5rA-0001jk-PR for emacs-devel@gnu.org; Tue, 03 Jan 2012 10:01:00 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:47692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri5rA-0001jU-8g for emacs-devel@gnu.org; Tue, 03 Jan 2012 10:00:52 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ri5r8-0004Y6-8s for emacs-devel@gnu.org; Tue, 03 Jan 2012 16:00:50 +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 ; Tue, 03 Jan 2012 16:00:50 +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 ; Tue, 03 Jan 2012 16:00:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 76 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:/HtckVklXCGGxZrZZ1UttgKOVOU= 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:147212 Archived-At: On Tue, 03 Jan 2012 09:02:17 -0500 Eli Zaretskii wrote: >> From: Ted Zlatanov >> Date: Tue, 03 Jan 2012 08:06:51 -0500 >> >> On Tue, 03 Jan 2012 02:14:19 -0500 Eli Zaretskii wrote: >> >> OK, so let's do a restart after a DLL package install or upgrade. It's >> better than nothing. Can this process be reused for other DLLs like the >> libxpm DLL? Can we activate the new DLL after Emacs restarts, so the >> old one will remain active as long as Emacs is using it and the user is >> not forced to restart immediately? EZ> We can, although it'd probably still need some code changes. E.g., EZ> displaying the splash image at startup will automatically load an EZ> image library, and we will have to defer that until after the DLL is EZ> replaced. (Assuming I understand you correctly that you propose to EZ> run package.el in the new, restarted instance of Emacs and replace the EZ> DLL before it is first used.) The mechanism is not too important from a UI perspective, as long as it DTRT, and I don't know the W32 platform well enough to specify how it should operate. If you think replacing the DLL is possible entirely from within Emacs, I'm OK with that. As a first cut, could we have a gnutls-w32 package, version 3.09 currently, which when activated will download and install the 3.09 GnuTLS DLL if it's missing? Where should this DLL be written? Does W32 have APIs or mechanisms to update DLLs safely? As an alternate solution, could GnuTLS itself have an installer and an updater? >> I'm not sure if multiple Emacs processes are an important use case. I >> would guess it's an edge case on W32 EZ> Happens to me all the time when I'm working on some bug and have the EZ> "regular" Emacs running alongside. Also, I understand that some EZ> people who use Gnus have it run in a separate session. Emacs developers are always an edge case :) >> I'm not sure what you and Juanma want to say. That because we don't >> have salaried positions for tracking GnuTLS updates to Emacs, it's a >> burden? Or that we shouldn't even do it? Or that we need more people >> to run the Emacs infrastructure? What's the problem and how can we >> solve it? EZ> What I want to say is this: EZ> Bottom line, I feel that letting users download and unzip DLLs is by EZ> far more practical for this purpose than what you suggest. It also EZ> has the advantage of already working. Unlike other libraries we support with Emacs, we have a responsibility to the user to keep GnuTLS updated. The worst case is that their security is compromised, not that Emacs won't run. On W32 this is a worse problem than anywhere else IIUC (Mac OS X has MacPorts and GNU/Linux has a billion package managers). So, we either tell the user to download and unzip the GnuTLS DLLs every time there's a critical fix, or we do it automatically for them from the package.el UI, or we pass the responsibility to the GnuTLS developers to write an updater. I don't think we have the option, as responsible developers, of just ignoring that responsibility. On Tue, 3 Jan 2012 14:37:00 +0100 Juanma Barranquero wrote: JB> What I want to say is that is a problem already fixed elsewhere, and I JB> see no point in diverting resources to fix it again poorly. The problem of pushing out a critical GnuTLS fix to Emacs users on W32 is not fixed AFAIK. We just have a DLL in a zip file. Ted