From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48452: 28.0.50; flymake for elisp does not respect `load-path` Date: Sat, 23 Jul 2022 10:24:51 +0100 Message-ID: <87y1wkmba4.fsf@gmail.com> References: <8735unafob.fsf@gmail.com> <877d4hs084.fsf@gnus.org> <87v8s1untg.fsf@gmail.com> <874jzlp12v.fsf@gnus.org> <87wnchc75r.fsf@gmail.com> <87ilnzaa49.fsf@gnus.org> <87cze7780j.fsf@gmail.com> <87r12mogh9.fsf@gnus.org> <87fsj1tlgn.fsf@gnus.org> <87sfmy1b95.fsf@gmail.com> <87r12d9b8f.fsf@gnus.org> <87k08497in.fsf@gnus.org> <87wnc474xt.fsf@gnus.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="7749"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Max Brieiev , 48452@debbugs.gnu.org, monnier@iro.umontreal.ca To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 23 11:24:28 2022 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 1oFBN5-0001pi-5q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Jul 2022 11:24:27 +0200 Original-Received: from localhost ([::1]:39466 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFBN3-0005N6-FK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Jul 2022 05:24:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50344) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFBMg-0005Lk-M4 for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 05:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53754) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFBMg-0001GB-AS for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 05:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oFBMg-0007MQ-6f for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 05:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Jul 2022 09:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48452 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 48452-submit@debbugs.gnu.org id=B48452.165856822928268 (code B ref 48452); Sat, 23 Jul 2022 09:24:02 +0000 Original-Received: (at 48452) by debbugs.gnu.org; 23 Jul 2022 09:23:49 +0000 Original-Received: from localhost ([127.0.0.1]:43503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFBMS-0007Lr-P7 for submit@debbugs.gnu.org; Sat, 23 Jul 2022 05:23:49 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:36482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFBMP-0007LZ-6l for 48452@debbugs.gnu.org; Sat, 23 Jul 2022 05:23:48 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id g2so1356160wru.3 for <48452@debbugs.gnu.org>; Sat, 23 Jul 2022 02:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=mGMQPhU3duA4q0G+9deePAyTUwN2gTsL9SxwYUyIGZ4=; b=OVW/BeXB8IwDvJ5sAFYeqpeZdlu+7fuHkYqrw+O0j2vqkS5TtDkDeMruD/vtlf+7Kr p+w/xVuAGzuNyyBqZ3dLHfLwj3KzOPspMTuraRVvFBDnrcTNPd5A/3vPltDoP1X02bH8 ae/xzgsbNkVREpuLPQj4yTVoTeXyod6wqHzOaFvPoNOWq1qbQglzp8bJXhWkRvwdHi7L cjKACcsr6YpxSRyOfY68S7tVqmYr4IRb+jP/4FyxH8MUmQ1QhZZSPh1asmG9GnBYVHzY r3CMWGDCsQZGCwkyVNmnPXbGXtkhzB0qUuZIRbeZ5+NjhWmV7p8wJnrLEdR1NvKmpp3n aF9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version:content-transfer-encoding; bh=mGMQPhU3duA4q0G+9deePAyTUwN2gTsL9SxwYUyIGZ4=; b=S8IOBYp/RZ8izOpnsW1pYcYUbuiE8XuvF9efeCtdPMnY+evd1BezH/wg3aqhH640r3 bfPUGhD+HdnF+bD8MSvIbMBNaJ+VTjXMH+1utLOtu5TR8tBShtDdl4euFqfEoFi7T7Z+ zZBKb3qttkwKVixrIm2Q1Oig8wbUrvv5wKPT8mFOhmm2KrCfkpy1wC8m99RkQLSl0LQG uvLBRviY4UVqDOx2bymdZPfeeDA+BnkIbcHANov/etIdOoRfyZL2pwu/s9iqJvDCovjJ TyWV6gRU5sEboD3x9BkT9UdXed5EqKkCttVyrut/kY4MkumK4wryxFm3M/447lSJ1Hrf /fuw== X-Gm-Message-State: AJIora9mYMqWBTkuVCRDWtjuk60IaH5JDKkr+Jefon7IVrEPS1dfoa/y 2wQRm7l6eJ/1QSmKz5l7GpQ= X-Google-Smtp-Source: AGRyM1swYllZ/WHfM39eFcV52GU0mVV6fR684J1zZ/zXgla7LRVi1a0AXX+JebAQUoy9h4xgM3F/RQ== X-Received: by 2002:a5d:48c9:0:b0:21d:e031:151c with SMTP id p9-20020a5d48c9000000b0021de031151cmr2281548wrs.567.1658568219215; Sat, 23 Jul 2022 02:23:39 -0700 (PDT) Original-Received: from krug ([62.28.191.198]) by smtp.gmail.com with ESMTPSA id m126-20020a1ca384000000b003a03e63e428sm12791622wme.36.2022.07.23.02.23.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Jul 2022 02:23:38 -0700 (PDT) In-Reply-To: <87wnc474xt.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 23 Jul 2022 07:50:54 +0200") 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:237727 Archived-At: Lars Ingebrigtsen writes: > Jo=C3=A3o T=C3=A1vora writes: > >> If you don't elaborate, we have no way of understanding whether this >> is a genuine expansion of the "disaster vector" that is already >> intrinsic to this particular Flymake backend. > > I think I already mentioned the problem of editing files in /tmp/? > That's the whole point of not having ./ in load-path -- you can > inadvertently load code under control of an attacker. As I've been trying to explain, flymake-elisp-byte-compile is all about "inadvertently loading code": it's -- literally -- constantly and largely unpredictably byte-compiling a file containing the transient contents of your buffer. As you know, in Lisp, that is always running code, arbitrary code. It's not at all comparable to the interactive Emacs usage where the user takes voluntary action to execute something. Flymake in Elisp files is inherently insecure in this respect. This is why we don't turn it on by default. Maybe this should feature more prominently somewhere: "Users must NOT turn on flymake-elisp-byte-compile automatically if they are not aware of the risks." At some point in the past, Stefan was working on a "sandboxed" Emacs that could, in theory, pave the way for automatically enabled Elisp Flymake, but I haven't heard of that effort lately. > It seems to me that there's two useful values for load-path in the > Flymake backend: Either just the standard load-path (so that you > actually get the same results as when doing a batch byte-compile) or the > current running load-path (so that you get the same results as when you > `require' the file from your .emacs, say). Altering the load-path to > also include the ELPA directories doesn't really help much, because > people have all kinds of code that's not in ELPA (but is in their > load-path). I think we have to ask ourselves: what is Flymake used for? The most useful answers will come from the people who actually use it, though potential uses are also interesting. I for one use it to develop Elisp package.el packages that I later publish to GNU ELPA and MELPA so that other users, my "clients", are to be able to use in their Emacsen. The ELPA packages _I_ develop only ever depend on packages in Emacs core (at most they are :core ELPA packages). But it seems, quite reasonably, that Max's packages do also depend on packages that are not in Emacs core, but in some xELPA repo. Why is Flymake useful to me in the state it is now? Because, given a transient state of my Elisp buffers, it helps accurately predict the byte-compilation warnings and errors that those clients would experience were they to grab and install my package at state I have it in front of me. Having './' in the default load-path for elisp-flymake-byte-compile is fundamental for the accuracy of this prediction. Why? Because the clients of my packages -- regardless if they use package.el, straight.el, etc or just simply using a git checkout -- will always have the the files I have in some directory in some other directory in their machines, and _that_ directory will be in the load-path. Can Flymake be useful in some other situation? Perhaps, who knows? But I for one never use it to obtain largely the same results I can already get with M-x elisp-byte-compile-file. But if you do want to use it like that, feel free to add an option to inherit the current session's load path. I'd say we should first fix Max's problem, this bug report's problem, which I can perfectly understand. I think the correct way is with the patch I submitted, though we can also ask max to add the path of each of his package's dependencies to some dir-local value of elisp-flymake-byte-compile-load-path. Not very practical, IMO. Finally, if you want to remove "./" from the automatic load path of elisp-flymake-byte-compile, no problem. It's of course your call: I'll just add it to elisp-flymake-byte-compile-load-path in my session and be done with it. IMO Something like this could be justified if it were plugging an important security hole. But in my opinion we're closing a window in a house with no roof and doesn't justify breaking people's workflows.