From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths) Date: Mon, 10 Dec 2018 23:17:01 +0000 Message-ID: <87in019dle.fsf@gmail.com> References: <20181204233600.7907.75252@vcs0.savannah.gnu.org> <20181204233601.273DD209DC@vcs0.savannah.gnu.org> <87sgz89mpu.fsf_-_@gmail.com> <87mupe9qqw.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1544483719 977 195.159.176.226 (10 Dec 2018 23:15:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2018 23:15:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Glenn Morris , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 00:15:14 2018 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 1gWUle-00009J-Dv for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 00:15:14 +0100 Original-Received: from localhost ([::1]:35110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWUnl-0001PD-2q for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 18:17:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWUnc-0001P6-5W for emacs-devel@gnu.org; Mon, 10 Dec 2018 18:17:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWUnY-0001cD-SF for emacs-devel@gnu.org; Mon, 10 Dec 2018 18:17:16 -0500 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:43529) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gWUnY-0001Zd-Cp; Mon, 10 Dec 2018 18:17:12 -0500 Original-Received: by mail-wr1-x42e.google.com with SMTP id r10so12202883wrs.10; Mon, 10 Dec 2018 15:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=hQhXTGSEBsgjxkbo3uIJsxDbL/oz9Btbv9x2VWi0xyE=; b=R06OKZ1jKJ3rOoFPnONT/3+nLHOPeW313hkPX5gLaPdVHj4lLvIvR/l4ztYrrk7G9P BkosbtBwTMJ7h4XerrdDZ2x7tVpDXi0Us5HtcstMeqDTidtQimai20b3rfXqYjkwqBBj 8ajPgy/00433sLjfcDrnYj5qT0PTAMpBwyLv6LW2TWIZHXyAt1bbCit3Q8mNOmw6rQgJ o3xerge+gN7+3D2iexAs5YLirCTNnNxFUzEHJUOFxA/7Z8K7p9O8ptbndEhqStOh1s2y D78B1Yc9oQIKXTQT5L+QLVuUoPQzXBnjbvuLsfnqLMhozmBI83T0PxoGNF1L5ZC5JuB3 LGWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=hQhXTGSEBsgjxkbo3uIJsxDbL/oz9Btbv9x2VWi0xyE=; b=YaaX+BIUgDNo1uXIzZ5nLw5phyZkg5GWfecNPcDHAlb12VU/T2XxSoksUHHvJ5ehm8 DrZIEMpe5WMSGXDAYDpyGzBUwvj7BYFHN4IKqJLIG5h9ian+vhlOsd7wvtDoK8H+6jRq Uxjv/brm5iHhjV/gtla81QYqAw3bIcxlaZOnsaQdBkW0qeFczZTby1ZwuiGvI01SfbFw Aszg2XRGIV849a9BexgyYGo7MJh7VURC3Qv/xcRxthea10JmiOxlbQfCFGOEhiV7EmOG TZQ21YzYKmrUmyIa7gyBbOCu3aib04+I6L0K6CyEgPbaNOYgIV34YD9lSJWTY8yO/2Xh 8XjQ== X-Gm-Message-State: AA+aEWZTYSXpV/lz4o+ncUid+Vz5SEsrhLM1avT8L+aTVSCaxtV/tyI1 YgvF5H4boNJTzvyxFea6eP1ZW9ss X-Google-Smtp-Source: AFSGD/XXc0j5RW1Ry3JZOr8KL+Nf2x2LEYRyg+u7B4N0P8zSb48QpuYwnggsgy8/pVmG5P2/0Yu2Bw== X-Received: by 2002:a5d:660e:: with SMTP id n14mr11190370wru.19.1544483825497; Mon, 10 Dec 2018 15:17:05 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id l20sm34137342wrb.93.2018.12.10.15.17.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Dec 2018 15:17:04 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sun, 09 Dec 2018 21:22:36 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42e 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:231750 Archived-At: Stefan Monnier writes: > I'm saying "without another traversal of the code". > I.e. elisp-flymake--batch-compile-for-flymake would just call the > byte-compiler in a different way (either via a new entry-point, or by > let-binding some new variable) to cause it to be more careful (and not > worry about generating correct&efficient code). OK. Got it. > The macros defined in the flymake'd file wouldn't need any declaration: > they'd all be treated as suspicious and checked via `unsafep`. > > For the macros defined in already-loaded packages, I'm not sure > what would be the better option between a whitelist (such as the `flymake= -safe` > declaration above) or a blacklist or something in-between. Hmmm. The way I'm understanding this now, I'd favor a blacklist, because it seems that you are proposing that anything that is loaded in the main Emacs (call it "host" or "master"), is already safe, except for some known misbehaving macros. >> But then we would have to prompt the user to accept or reject these >> marks right? > > Since they're in the files we already trust I don't think that's > needed. Trust a file =3D loaded in the host Emacs - some known exceptions, right? >> I don't think I completely understood your idea: what about, for >> example, eglot.el's macrology that checks LSP interface destructuring at >> compile-time? There are some eval-when-compile's there right now: >> >> (eval-and-compile >> (defvar eglot--lsp-interface-alist >> `( >> (CodeAction (:title) (:kind :diagnostics :edit :command)) >> (Command (:title :command) (:arguments)) >> ...) >> "Alist of (INTERFACE REQUIRED-KEYS OPTIONAL-KEYS)")) >> >> And then >> >> (eglot--dbind ((Command) title not-really-a-key) some-lsp-object >> (do-something-with title not-really-a-key)) >> >> gives me a nice warning that not-really-a-key isn't in the "Command" >> interface. How would that work in your new elisp-flymake-byte-compile? > > It would only work once `eglot--dbind` is defined by a pakage in > `load-path` (and after that package defined > eglot--lsp-interface-alist). > > But not if you just open eglot.el. So as soon as I load eglot.el, or eglot.elc in the host Emacs, it would start working? If so, I could live with that. Until it starts working it could issue some diagnostics saying "this macro is not known to be safe, so not checking". Now, how would you transmit this information about safe and unsafe macros to from the host Emacs to the slave byte-compiling Emacs which is a separate process? Via command-line parameters, an .el generated on the fly (we already do this for the flymake'd file, btw), or something else? > >> Also, what do you think of my option 2 to disable most of the system >> interface when flymaking? > > Providing ways to run Elisp in a confined environment would be useful in > various circumstances, but it's non-trivial. I can understand that, but I'm not proposing a fully hermetic sandbox just something that ameliorates the problem. At least, the way I understand your solution for the "safe/unsafe" macro problem it still doesn't seem to fix the fact that as soon as I type "(launch-nuke)" into some already loaded macro in eglot.el, nukes are potentially going to be launched by some unsuspecting macro-expansion down below. So I'd like at least to have a slave emacs with main nuke-launching facilities disabled, even if there are almost certainly ways to circumvent that. Jo=C3=A3o