From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#45198: 28.0.50; Sandbox mode Date: Thu, 31 Dec 2020 16:05:52 +0100 Message-ID: References: <838s9gk476.fsf@gnu.org> <834kk4k090.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="894"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Bastien , 45198@debbugs.gnu.org, Stefan Monnier , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 31 16:11:26 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 1kuzbq-00008t-3E for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 31 Dec 2020 16:11:26 +0100 Original-Received: from localhost ([::1]:54242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuzbp-0006tS-3u for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 31 Dec 2020 10:11:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuzXa-0004Mw-QD for bug-gnu-emacs@gnu.org; Thu, 31 Dec 2020 10:07:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57953) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuzXa-0001xH-4P for bug-gnu-emacs@gnu.org; Thu, 31 Dec 2020 10:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kuzXZ-0008GP-Rb for bug-gnu-emacs@gnu.org; Thu, 31 Dec 2020 10:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Dec 2020 15:07: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.160942717131696 (code B ref 45198); Thu, 31 Dec 2020 15:07:01 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 31 Dec 2020 15:06:11 +0000 Original-Received: from localhost ([127.0.0.1]:41262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuzWl-0008F7-2t for submit@debbugs.gnu.org; Thu, 31 Dec 2020 10:06:11 -0500 Original-Received: from mail-oi1-f170.google.com ([209.85.167.170]:34237) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuzWj-0008Eq-CM for 45198@debbugs.gnu.org; Thu, 31 Dec 2020 10:06:10 -0500 Original-Received: by mail-oi1-f170.google.com with SMTP id s75so22080275oih.1 for <45198@debbugs.gnu.org>; Thu, 31 Dec 2020 07:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gCpSkdnajqlsmVxlxtmIij79CuTU52UYUJAAy24CDyY=; b=JAk/J8f1hjlgzdbUBm4ys6ys61FG/loOZKmMSXD+NtmN/SOg/s5TEcE594x/I9vK+u Qsv8UtkRHmqhQTCuF/SHoRe3fnebpNIDCfZpix+msqHIUzg1baM3GmUeuAOy93/GegUo N2s3g8+K3rnbWUE1RNFmHB4vY8ax+aSxSkInv+UBJGAauVPFjoxWs0Tfjmx6aEiTCbR1 h8qrDLMWc6CRsX1Nz4xkL9GEWhALMBhWpWXrR1OalY2hf46Mdji2v7JyjMxloHftlMZm zbNHdTXu7DKydOK+fRgcW/iSlSCK17zFjHGd2Jjv9PDYJ0UDbpNEGM3y4SPwPHMB4CrR NFsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gCpSkdnajqlsmVxlxtmIij79CuTU52UYUJAAy24CDyY=; b=H6TLCd/e3SXxALkR/GhpdGXvAOKePake+Moww6jz5+Icql372ZcI9Sjy+g86rU08bR /RxDd1tdMNY1Wl0ui4mSAc51pMsF8Rt03j6DKSzOlb60SMIon9lJirsh/3t8tuGUTsEW ZTp60DEaMO8RpIBB1LVVJ6Kkq+MeQWLoXTNX+jx75sQKJBRZuPGWqmc8+vanxxMEcHrU 0hddlmnkRSqdSkxUze6FVY0DhcOFP7YlgVMd34eh4UbvYuEqMb9hJe+6ejz46WFvOAAb mW9jVrOGDoILpTVVIV9eRNMOi0LS9ab59sx8+/74o0yaKb/wxOlTcAtbrXL6fOZcV2l1 7+Fw== X-Gm-Message-State: AOAM532guj+KW1mPaiqbGkUq8m5JCmNABMHNDenwKy/M+SJzca9w8fQl oUMZHYHkCwwb97sOUF7GpbfHK1BhcnPIDLS5lms= X-Google-Smtp-Source: ABdhPJxymbfGPyU+RGA7E4gCo357blvhSydfXMv9pz6egY3ELfQWaCrZ8RX/evlcTwQU9DAJmpJqVIyaDLMck4HAaRQ= X-Received: by 2002:a54:4881:: with SMTP id r1mr8036307oic.9.1609427163664; Thu, 31 Dec 2020 07:06:03 -0800 (PST) In-Reply-To: <834kk4k090.fsf@gnu.org> 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:197093 Archived-At: Am Di., 29. Dez. 2020 um 18:09 Uhr schrieb Eli Zaretskii : > > > From: Philipp Stephani > > Date: Tue, 29 Dec 2020 17:05:33 +0100 > > Cc: Stefan Monnier , Bastien , 4= 5198@debbugs.gnu.org, > > Jo=C3=A3o T=C3=A1vora > > > > 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 brea= k > > > 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. That's a fair point, but does the mere presence of these replacements really break the build? Could we somehow make them not break the build? > > > > . Gnulib modules pulled to support seccomp should be disabled in th= e > > > 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. Independent of this discussion, are there ways to reduce the size of the auditing job? I'd hope that eventually the only thing needed would be to run the test suite (which ideally would happen automatically on Gitlab/Emba). For developers not on Windows, it's unfortunately difficult to predict whether a specific change will break the Windows build or not, and the large difference between the Windows and other builds doesn't make this easier. > > > > . header files used to support seccomp code should be #ifdef'ed by > > > HAVE_LINUX_SECCOMP_H or similar, and likewise with any code neede= d > > > 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. Sure, it's not needed, but does it actually break the build? I'd rather limit the number of preprocessor statements as much as possible (and reasonable). > > > 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. Thanks, no pressure, this clearly isn't urgent. > > > > 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 tha= t > > > 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. Yeah, there are pros and cons for either approach. Typically, reusing code is the way to go, since code is a liability, and the less we have to maintain, the better. But I do see your point that using Gnulib is too much of a burden for Windows right now (though I still hope that we can eventually improve Gnulib enough that we can use it directly on Windows). I've now created a new branch scratch/seccomp-no-gnulib-2 that uses fopen directly, without Gnulib dependencies. (I considered using emacs_fopen, but since that allows users to quit and therefore in theory can run Lisp code, I'm not sure we can use it here. Also, since this only works on GNU/Linux, we don't have to deal with Windows filenames.)