From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Win32 GnuTLS DLL installer? Date: Thu, 21 Sep 2017 21:31:55 +0300 Message-ID: <838th7ewdg.fsf@gnu.org> References: <87lgl9e4ji.fsf@lifelogs.com> <5e2a6b84f4051ba2d4d427200045c947.squirrel@cloud103.planethippo.com> <8760ccdt3g.fsf@lifelogs.com> <83mv5ods3n.fsf@gnu.org> <87zi9ocbae.fsf@lifelogs.com> <83fubgdm4y.fsf@gnu.org> <87vakcc5xn.fsf@lifelogs.com> <83a81odk0q.fsf@gnu.org> <87poakc4th.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1506018793 21963 195.159.176.226 (21 Sep 2017 18:33:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 21 Sep 2017 18:33:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 21 20:33:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dv6Hb-0005Cn-KA for ged-emacs-devel@m.gmane.org; Thu, 21 Sep 2017 20:33:07 +0200 Original-Received: from localhost ([::1]:55063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dv6Hh-0008OB-2D for ged-emacs-devel@m.gmane.org; Thu, 21 Sep 2017 14:33:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dv6Gp-0008Lc-1T for emacs-devel@gnu.org; Thu, 21 Sep 2017 14:32:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dv6Gl-0004XD-Pl for emacs-devel@gnu.org; Thu, 21 Sep 2017 14:32:19 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dv6Gl-0004X4-NC; Thu, 21 Sep 2017 14:32:15 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dv6Gj-0003gW-1F; Thu, 21 Sep 2017 14:32:15 -0400 In-reply-to: <87poakc4th.fsf@lifelogs.com> (message from Ted Zlatanov on Thu, 21 Sep 2017 13:57:46 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:218648 Archived-At: > From: Ted Zlatanov > Date: Thu, 21 Sep 2017 13:57:46 -0400 > > EZ> Available from where? Surely, we won't want to recommend > EZ> security-related DLLs whose quality we cannot guarantee, would we? > > As Phillip said, > https://ftp.gnu.org/gnu/emacs/windows/emacs-25-x86_64-deps.zip and > whatever other locations on that server are appropriate. I think that's > the simplest, least surprising solution. It may be the simplest, but are they good enough for a dedicated, security-related package? I'm not sure. E.g., do the MSYS2 people, who produce the DLLs which Phillip repackages, habitually run the test suite of those DLLs, and investigate every failure? > EZ> Bottom line, I'd really love to see someone volunteer to do this job > EZ> in a way that we could simply rely on them and point to their site (or > EZ> copy stuff from there to ELPA), but I'm not holding my breath, having > EZ> done that several times myself. It's not an easy job, and requires > EZ> non-trivial investment of time and effort. > > I understand your concerns. They apply equally to the rest of the W32 > binaries and dependencies and I'm not ignoring them. They do, but producing a security-catering package brings on additional concerns. And I'm not sure our simple practices are up to the challenge. > When a GitLab server is available, maybe we can set up a W32 build slave > to build and test these binaries. That'd be good progress, but someone will still have to review the failures in the optional libraries and fix them. The upstream developers only do that for GNU/Linux builds.