From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45198: 28.0.50; Sandbox mode Date: Tue, 29 Dec 2020 19:09:15 +0200 Message-ID: <834kk4k090.fsf@gnu.org> References: <838s9gk476.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19492"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bzg@gnu.org, 45198@debbugs.gnu.org, monnier@iro.umontreal.ca, joaotavora@gmail.com To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 29 18:10:24 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuIVr-0004y8-RB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 18:10:23 +0100 Original-Received: from localhost ([::1]:58020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuIVq-0002zC-TH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 12:10:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuIVW-0002wd-As for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 12:10:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56752) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuIVW-0007Ay-3X for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 12:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kuIVV-0002Ul-Ty for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 12:10:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Dec 2020 17:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45198 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 45198-submit@debbugs.gnu.org id=B45198.16092617739530 (code B ref 45198); Tue, 29 Dec 2020 17:10:01 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 29 Dec 2020 17:09:33 +0000 Original-Received: from localhost ([127.0.0.1]:40065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuIV2-0002Td-Ru for submit@debbugs.gnu.org; Tue, 29 Dec 2020 12:09:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuIUz-0002TG-HQ for 45198@debbugs.gnu.org; Tue, 29 Dec 2020 12:09:32 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34551) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuIUu-00075t-9Y; Tue, 29 Dec 2020 12:09:24 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3156 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kuIUs-0005dl-PV; Tue, 29 Dec 2020 12:09:23 -0500 In-Reply-To: (message from Philipp Stephani on Tue, 29 Dec 2020 17:05:33 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:196954 Archived-At: > From: Philipp Stephani > Date: Tue, 29 Dec 2020 17:05:33 +0100 > Cc: Stefan Monnier , Bastien , 45198@debbugs.gnu.org, > João Távora > > Am Di., 29. Dez. 2020 um 16:44 Uhr schrieb Eli Zaretskii : > > > > > It would be great if someone could test whether the Windows build > > > still works after that, thanks! > > > > I only skimmed the changes, but I'm already quite sure they will break > > the Windows build. > > Why? Everything should be behind ifdefs/conditional compilation, > otherwise compilation on macOS would also break. Because some/many Gnulib replacements are incompatible with how the w32 port of Emacs works. In particular, functions which operate on file names don't support UTF-8 encoded file names; Gnulib's 'stat' and 'fstat' don't support security-related features from which we glean owner and group of files; network-related functions need special handling in Emacs to support subprocess functionality; etc. > > . Gnulib modules pulled to support seccomp should be disabled in the > > MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or > > nt/gnulib-cfg.mk; and > > This shouldn't be necessary, as Gnulib is compatible with Windows (I > guess, since we use it elsewhere) Not when Emacs is concerned, see above. We use only small parts of Gnulib on Windows, for those reasons. And we don't use any Gnulib functions that accept file names. > (That's also what gnulib-cfg.mk says: "In general, do NOT omit modules > that don't need to be omitted, to minimize the differences from > upstream gnulib.mk and thus make the maintenance easier.") I know; I wrote that. However, this talks about code that will be actually _used_ in the Windows build, whereas here we are talking about "ballast": the related code will not be used at all. So it makes sense not to make our job harder by adding unnecessary code, which then will need to be audited for compatibility. Your Gnulib import adds quite a lot of modules, which makes the audit a large job. > > . header files used to support seccomp code should be #ifdef'ed by > > HAVE_LINUX_SECCOMP_H or similar, and likewise with any code needed > > for seccomp and unnecessary otherwise. > > That should already be the case. It isn't, at least not in general. Just one example: diff --git a/src/emacs.c b/src/emacs.c index 2a32083..a044535 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -33,6 +33,8 @@ along with GNU Emacs. If not, see . */ #include "lisp.h" #include "sysstdio.h" +#include <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< This header is included unconditionally, although it shouldn't be needed on Windows. > Turning the question around: is building the branch on Windows > actually broken? If so, what are the error messages? I didn't have time to build it, and probably won't have enough time in the following days, sorry. I have the co-maintainer job to do, and there's a pretest of Emacs 27.2 under way on top of that. So I cannot show the error messages. Others are encouraged to try the branch and report the actual problems; I just wanted to give a heads-up, in the hope that it will help adapting and merging the branch sooner. > > Btw, I wonder why you needed to import the read-file module from > > Gnulib -- does it provide any features that we couldn't implement on > > our own? I'm asking because that module caused you to pull in quite a > > few dependency modules from Gnulib, and I'm asking myself whether that > > is really justified. > > We could implement it ourselves, if we wanted, and in an earlier > version of the code I did that. But it's easier and less error-prone > to reuse an existing library. I question the wisdom of that, FWIW. Every unnecessary dependency on Gnulib is IMO an addition to the maintenance burden. It also makes the job of adapting the Windows build harder, because for example Gnulib's fopen cannot be used in Emacs on Windows, whereas we have emacs_fopen for the same purpose, which doesn't have that problem.