From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#45198: 28.0.50; Sandbox mode Date: Sat, 19 Dec 2020 13:11:56 -0500 Message-ID: References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@acm.org> <26556EDE-9133-450F-9181-2859E058677C@acm.org> <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@acm.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12280"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Bastien , 45198@debbugs.gnu.org, Philipp Stephani , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 19 19:13:19 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 1kqgjH-00036T-80 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Dec 2020 19:13:19 +0100 Original-Received: from localhost ([::1]:55880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqgjG-0007yZ-9t for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Dec 2020 13:13:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57364) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqgj1-0007xi-20 for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2020 13:13:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kqgiz-00087U-PU for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2020 13:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kqgiz-0007KB-KT for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2020 13:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Dec 2020 18:13: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.160840152728072 (code B ref 45198); Sat, 19 Dec 2020 18:13:01 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 19 Dec 2020 18:12:07 +0000 Original-Received: from localhost ([127.0.0.1]:43113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqgi7-0007Ii-9t for submit@debbugs.gnu.org; Sat, 19 Dec 2020 13:12:07 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqgi4-0007IB-98 for 45198@debbugs.gnu.org; Sat, 19 Dec 2020 13:12:06 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0971F809A5; Sat, 19 Dec 2020 13:11:59 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7FA7380668; Sat, 19 Dec 2020 13:11:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1608401517; bh=pn3XQHTzzJAMfq4kW8xwVQbUyw64LIaMVfMsvROlauI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FQf6BajSU6AU2HyEppyDBGy38AL5ElOo+KYB5KuKqb/OZJfgNLOpixAhuc0qYrImx cKKvrLbmgsDGDu3NgTPx3O2QIl2IjsxYXPFYOXFX5Qvae0FrvPPvYlfWXOQeYmJmXX PFx9WU9ufpeBc9Dis+gPOHfDrx9I08g+iWucZd5Thu1je9XQuaeb32e9h+kVT7UbBJ l4uD6rfFQxE5+BJA5AXiM8Cc1mbnXl7/4fDChgyipKvKmVD5cBywAdCvEwd7qPKE3K hFBWLrSqqDlC1vswevTp75YiUXkZU14g9pRsAj7BHfHm66XKoZxR/6KkbxNjWH7MnQ BbMEKdVmckV5g== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2FD7B1202C2; Sat, 19 Dec 2020 13:11:57 -0500 (EST) In-Reply-To: <414E5ED4-0105-43FF-9DF5-D5A2E32E586B@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Sat, 19 Dec 2020 18:19:32 +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:196408 Archived-At: [ I'm afraid I dropped out of the discussion, so I may lack some context. ] > What I meant is that there is no way of knowing whether an API is rubbish or > not without having put it to use ourselves first (preferably in two or more > ways), so let's not front-load the design. We know that this is true > regardless of how good programmers we think we are. > Flymake would be a natural user, but it must cope with our own demands first. IIUC the discussion surrounds mostly around restricting file-reads, right? I agree it'd be good to have a sandbox that restricts file-reads, but we should think about how to design such a thing, i.e. how to specify (and then enforce) which files can be read. My experience with the GNU ELPA scripts using bwrap is that it might not be easy: we definitely don't want to give read access to /etc, yet it seems very likely that some files in /etc may be needed, even in very mundane circumstances (e.g. /etc/alternatives or /etc/emacs or ...). This gets quickly very OS-dependent (and doesn't depend just on Windows-vs-GNU/Linux but varies also between distributions of GNU/Linux). If we stick to an "in-process" sandbox (i.e. you can't run sub-processes) it makes this a bit simpler (you don't need to worry about read access to /lib vs /lib64 and other such things), so maybe it is manageable. But I think the starting point would be to give read access to everything that's under one of the directories mentioned in `load-path`. > There's a difference though: flycheck is installed by someone who wants to > use it and is presumably ready for some setting-up. In contrast, we are > aiming at an on-by-default zero-configuration Emacs feature, which means > that the bar is higher. It's meant precisely for those who would not install > and configure flycheck, so false positives may have effects opposite > the intended. Indeed, in order to enable flymake by default we're going to have to be extra careful to try and make sure the user isn't smothered in warnings. That probably means for example to keep flymake disabled when visiting the init file. >> I also think that packages shouldn't rely on autoloads from other >> packages. I generally dislike autoloads and think they are overused. >> They make programming unnecessarily brittle because they assume not >> only that the load path is set up correctly, but also that the correct >> loaddefs files are already loaded. Autoloads are probably fine for >> interactive commands to avoid unnecessarily loading rarely-used >> packages, but inter-package dependencies should just use 'require'. > I don't necessarily disagree but it would be interesting to hear what Stefan > thinks about it. Since it's somewhat of an opinionated tool after all, it's > squarely within our remit to lay down policy... I must say I don't know what's being discussed here. What autoloads? Why do we care? Stefan