GNU bug report logs -
#70440
[PATCH] Use -P switch when calling 'python-interpreter'
Previous Next
To reply to this bug, email your comments to 70440 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Wed, 17 Apr 2024 18:24:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Augusto Stoffel <arstoffel <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 17 Apr 2024 18:24:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
The attachment should be self-explanatory, otherwise let me know.
[0001-Use-P-switch-when-calling-python-interpreter.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Wed, 17 Apr 2024 19:15:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Wed, 17 Apr 2024 20:23:30 +0200
>
> The attachment should be self-explanatory, otherwise let me know.
>
>
> >From 04db8a3fbb29f497fdc728f4413aea162650b30b Mon Sep 17 00:00:00 2001
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Wed, 17 Apr 2024 20:17:22 +0200
> Subject: [PATCH] Use -P switch when calling 'python-interpreter'
>
> This excludes the current directory from Python's module load path,
> which can be unsafe.
>
> * lisp/progmodes/python.el (python--list-imports): Use -P switch
> (python--do-isort): Use -P switch
> (python-fix-imports): Use -P switch
> ---
> lisp/progmodes/python.el | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
> index 85279d3e84b..180a8357aad 100644
> --- a/lisp/progmodes/python.el
> +++ b/lisp/progmodes/python.el
> @@ -6805,7 +6805,7 @@ python--list-imports
> (append
> (split-string-shell-command
> python-interpreter-args)
> - `("-c" ,python--list-imports)
> + `("-Pc" ,python--list-imports)
> (list (or name "")))))
> (with-current-buffer buffer
> (apply #'call-process
> @@ -6814,7 +6814,7 @@ python--list-imports
> (append
> (split-string-shell-command
> python-interpreter-args)
> - `("-c" ,python--list-imports)
> + `("-Pc" ,python--list-imports)
> (list (or name ""))
> (mapcar #'file-local-name source))))))
> lines)
> @@ -6862,7 +6862,7 @@ python--do-isort
> (append
> (split-string-shell-command
> python-interpreter-args)
> - '("-m" "isort" "-")
> + '("-Pm" "isort" "-")
> args)))
> (tick (buffer-chars-modified-tick)))
> (unless (eq 0 status)
> @@ -6940,7 +6940,7 @@ python-fix-imports
> (append
> (split-string-shell-command
> python-interpreter-args)
> - '("-m" "pyflakes"))))
> + '("-Pm" "pyflakes"))))
> (goto-char (point-min))
> (when (looking-at-p ".* No module named pyflakes$")
> (error "%s couldn't find pyflakes" python-interpreter))
> --
> 2.44.0
>
Thanks.
kobarity, any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Thu, 18 Apr 2024 15:27:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 70440 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> > From: Augusto Stoffel <arstoffel <at> gmail.com>
> > Date: Wed, 17 Apr 2024 20:23:30 +0200
> >
> > The attachment should be self-explanatory, otherwise let me know.
> >
> >
> > >From 04db8a3fbb29f497fdc728f4413aea162650b30b Mon Sep 17 00:00:00 2001
> > From: Augusto Stoffel <arstoffel <at> gmail.com>
> > Date: Wed, 17 Apr 2024 20:17:22 +0200
> > Subject: [PATCH] Use -P switch when calling 'python-interpreter'
> >
> > This excludes the current directory from Python's module load path,
> > which can be unsafe.
> >
> > * lisp/progmodes/python.el (python--list-imports): Use -P switch
> > (python--do-isort): Use -P switch
> > (python-fix-imports): Use -P switch
> > ---
> > lisp/progmodes/python.el | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
> > index 85279d3e84b..180a8357aad 100644
> > --- a/lisp/progmodes/python.el
> > +++ b/lisp/progmodes/python.el
> > @@ -6805,7 +6805,7 @@ python--list-imports
> > (append
> > (split-string-shell-command
> > python-interpreter-args)
> > - `("-c" ,python--list-imports)
> > + `("-Pc" ,python--list-imports)
> > (list (or name "")))))
> > (with-current-buffer buffer
> > (apply #'call-process
> > @@ -6814,7 +6814,7 @@ python--list-imports
> > (append
> > (split-string-shell-command
> > python-interpreter-args)
> > - `("-c" ,python--list-imports)
> > + `("-Pc" ,python--list-imports)
> > (list (or name ""))
> > (mapcar #'file-local-name source))))))
> > lines)
> > @@ -6862,7 +6862,7 @@ python--do-isort
> > (append
> > (split-string-shell-command
> > python-interpreter-args)
> > - '("-m" "isort" "-")
> > + '("-Pm" "isort" "-")
> > args)))
> > (tick (buffer-chars-modified-tick)))
> > (unless (eq 0 status)
> > @@ -6940,7 +6940,7 @@ python-fix-imports
> > (append
> > (split-string-shell-command
> > python-interpreter-args)
> > - '("-m" "pyflakes"))))
> > + '("-Pm" "pyflakes"))))
> > (goto-char (point-min))
> > (when (looking-at-p ".* No module named pyflakes$")
> > (error "%s couldn't find pyflakes" python-interpreter))
> > --
> > 2.44.0
> >
>
> Thanks.
>
> kobarity, any comments?
The -P switch is new, introduced in CPython 3.11, so I don't think it
can be added unconditionally. Furthermore, `python-interpreter' may
not be CPython. Isn't it enough to customize
`python-interpreter-args'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Thu, 18 Apr 2024 15:53:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 70440 <at> debbugs.gnu.org (full text, mbox):
On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
> The -P switch is new, introduced in CPython 3.11, so I don't think it
> can be added unconditionally. Furthermore, `python-interpreter' may
> not be CPython. Isn't it enough to customize
> `python-interpreter-args'?
Ah, too bad. So let's send that option via environment variables. I'll
make a new patch when I get the chance.
This patch is a quite important fix and shouldn't be left to a
customization. Without it, you need to trust the .py files in the
current directory. Moreover any name clashes with the built-in library
module names can crash the commands (just happened to me).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Thu, 18 Apr 2024 15:59:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70440 <at> debbugs.gnu.org
> Date: Thu, 18 Apr 2024 17:52:21 +0200
>
> On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
>
> > The -P switch is new, introduced in CPython 3.11, so I don't think it
> > can be added unconditionally. Furthermore, `python-interpreter' may
> > not be CPython. Isn't it enough to customize
> > `python-interpreter-args'?
>
> Ah, too bad. So let's send that option via environment variables. I'll
> make a new patch when I get the chance.
Maybe we should discuss this before you sit down to write and text the
code. Pushing things into the environment has its downsides: those
environment variables then affect all the subordinate processes,
including their children, grandchildren etc. This is not always
wanted.
One alternative to environment variables would be detecting whether -P
is supported before the first time we invoke Python. We do similar
stuff for Grep and other programs we invoke.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Thu, 18 Apr 2024 16:03:04 GMT)
Full text and
rfc822 format available.
Message #20 received at 70440 <at> debbugs.gnu.org (full text, mbox):
On Thu, 18 Apr 2024 at 18:57, Eli Zaretskii wrote:
>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70440 <at> debbugs.gnu.org
>> Date: Thu, 18 Apr 2024 17:52:21 +0200
>>
>> On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
>>
>> > The -P switch is new, introduced in CPython 3.11, so I don't think it
>> > can be added unconditionally. Furthermore, `python-interpreter' may
>> > not be CPython. Isn't it enough to customize
>> > `python-interpreter-args'?
>>
>> Ah, too bad. So let's send that option via environment variables. I'll
>> make a new patch when I get the chance.
>
> Maybe we should discuss this before you sit down to write and text the
> code. Pushing things into the environment has its downsides: those
> environment variables then affect all the subordinate processes,
> including their children, grandchildren etc. This is not always
> wanted.
In this case we would just let-bind the env variable for this specific
subprocess call only. It's no different than passing a command-line
switch.
> One alternative to environment variables would be detecting whether -P
> is supported before the first time we invoke Python. We do similar
> stuff for Grep and other programs we invoke.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Thu, 18 Apr 2024 16:15:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: kobarity <at> gmail.com, 70440 <at> debbugs.gnu.org
> Date: Thu, 18 Apr 2024 18:02:34 +0200
>
> On Thu, 18 Apr 2024 at 18:57, Eli Zaretskii wrote:
>
> >> From: Augusto Stoffel <arstoffel <at> gmail.com>
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70440 <at> debbugs.gnu.org
> >> Date: Thu, 18 Apr 2024 17:52:21 +0200
> >>
> >> On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
> >>
> >> > The -P switch is new, introduced in CPython 3.11, so I don't think it
> >> > can be added unconditionally. Furthermore, `python-interpreter' may
> >> > not be CPython. Isn't it enough to customize
> >> > `python-interpreter-args'?
> >>
> >> Ah, too bad. So let's send that option via environment variables. I'll
> >> make a new patch when I get the chance.
> >
> > Maybe we should discuss this before you sit down to write and text the
> > code. Pushing things into the environment has its downsides: those
> > environment variables then affect all the subordinate processes,
> > including their children, grandchildren etc. This is not always
> > wanted.
>
> In this case we would just let-bind the env variable for this specific
> subprocess call only. It's no different than passing a command-line
> switch.
Don't then the child processes of that python subprocess inherit the
same variable in their environments? That's what I meant by what I
wrote above: all of the descendants of our sub-process will inherit
the variable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 06:10:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 70440 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
> The -P switch is new, introduced in CPython 3.11, so I don't think it
> can be added unconditionally. Furthermore, `python-interpreter' may
> not be CPython. Isn't it enough to customize
> `python-interpreter-args'?
After sleeping on this, I recommend using -P anyway and simply failing
if the installed Python is too old.
The reason is that this has a security implication, similar to the
recent Org mode Latex preview situation. Without -P the user is tacitly
trusting the contents of the current directory. By tricking an user
into downloading a malicious file with an intentional name clash (say
via git pull), arbitrary code could in principle be executed on the
user's machine.
The -P switch completely removes this possibility, and conversely,
without -P there seems to be no reasonable way to make Python safe.
I've attached a new patch that informs the user why the commands failed
when Python is too old, which is good enough in my opinion. Note also
that this change only affects the Python import management commands,
which is a very handy but by no means essential feature.
[0001-Use-P-switch-when-calling-python-interpreter.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 07:16:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70440 <at> debbugs.gnu.org
> Date: Fri, 19 Apr 2024 08:08:43 +0200
>
> On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
>
> > The -P switch is new, introduced in CPython 3.11, so I don't think it
> > can be added unconditionally. Furthermore, `python-interpreter' may
> > not be CPython. Isn't it enough to customize
> > `python-interpreter-args'?
>
> After sleeping on this, I recommend using -P anyway and simply failing
> if the installed Python is too old.
>
> The reason is that this has a security implication, similar to the
> recent Org mode Latex preview situation. Without -P the user is tacitly
> trusting the contents of the current directory. By tricking an user
> into downloading a malicious file with an intentional name clash (say
> via git pull), arbitrary code could in principle be executed on the
> user's machine.
>
> The -P switch completely removes this possibility, and conversely,
> without -P there seems to be no reasonable way to make Python safe.
>
> I've attached a new patch that informs the user why the commands failed
> when Python is too old, which is good enough in my opinion. Note also
> that this change only affects the Python import management commands,
> which is a very handy but by no means essential feature.
Doing it this way would be an annoyance. Users could have
less-than-the-latest Python (or non-CPython version) installed for any
number of reasons, and it is not our business to annoy them because of
this. Security of using Python is not our concern, it is the user's
concern.
So I'd prefer that the change probed the support for the -P switch
when the relevant Emacs commands/functions are first invoked, and used
that if -P is supported, without any annoying messages. Do you see
any problems with such an approach?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 15:23:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 70440 <at> debbugs.gnu.org (full text, mbox):
On Fri, 19 Apr 2024 at 10:15, Eli Zaretskii wrote:
>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70440 <at> debbugs.gnu.org
>> Date: Fri, 19 Apr 2024 08:08:43 +0200
>>
>> On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
>>
>> > The -P switch is new, introduced in CPython 3.11, so I don't think it
>> > can be added unconditionally. Furthermore, `python-interpreter' may
>> > not be CPython. Isn't it enough to customize
>> > `python-interpreter-args'?
>>
>> After sleeping on this, I recommend using -P anyway and simply failing
>> if the installed Python is too old.
>>
>> The reason is that this has a security implication, similar to the
>> recent Org mode Latex preview situation. Without -P the user is tacitly
>> trusting the contents of the current directory. By tricking an user
>> into downloading a malicious file with an intentional name clash (say
>> via git pull), arbitrary code could in principle be executed on the
>> user's machine.
>>
>> The -P switch completely removes this possibility, and conversely,
>> without -P there seems to be no reasonable way to make Python safe.
>>
>> I've attached a new patch that informs the user why the commands failed
>> when Python is too old, which is good enough in my opinion. Note also
>> that this change only affects the Python import management commands,
>> which is a very handy but by no means essential feature.
>
> Doing it this way would be an annoyance. Users could have
> less-than-the-latest Python (or non-CPython version) installed for any
> number of reasons, and it is not our business to annoy them because of
> this. Security of using Python is not our concern, it is the user's
> concern.
>
> So I'd prefer that the change probed the support for the -P switch
> when the relevant Emacs commands/functions are first invoked, and used
> that if -P is supported, without any annoying messages. Do you see
> any problems with such an approach?
>
> Thanks.
Okay, you are the maintainer, but I hope I explained well that this is a
security hole.
(Apart from the security aspect, without -P the tool will just
mysteriously stop working if a file with a name such as csv.py is added
to the project; that's what happened to me. Perhaps outright not
working and explaining why is not as bad as working fine until it
doesn't anymore.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 15:42:04 GMT)
Full text and
rfc822 format available.
Message #35 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: kobarity <at> gmail.com, 70440 <at> debbugs.gnu.org
> Date: Fri, 19 Apr 2024 17:21:48 +0200
>
> On Fri, 19 Apr 2024 at 10:15, Eli Zaretskii wrote:
>
> >> From: Augusto Stoffel <arstoffel <at> gmail.com>
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70440 <at> debbugs.gnu.org
> >> Date: Fri, 19 Apr 2024 08:08:43 +0200
> >>
> >> On Fri, 19 Apr 2024 at 00:25, kobarity wrote:
> >>
> >> > The -P switch is new, introduced in CPython 3.11, so I don't think it
> >> > can be added unconditionally. Furthermore, `python-interpreter' may
> >> > not be CPython. Isn't it enough to customize
> >> > `python-interpreter-args'?
> >>
> >> After sleeping on this, I recommend using -P anyway and simply failing
> >> if the installed Python is too old.
> >>
> >> The reason is that this has a security implication, similar to the
> >> recent Org mode Latex preview situation. Without -P the user is tacitly
> >> trusting the contents of the current directory. By tricking an user
> >> into downloading a malicious file with an intentional name clash (say
> >> via git pull), arbitrary code could in principle be executed on the
> >> user's machine.
> >>
> >> The -P switch completely removes this possibility, and conversely,
> >> without -P there seems to be no reasonable way to make Python safe.
> >>
> >> I've attached a new patch that informs the user why the commands failed
> >> when Python is too old, which is good enough in my opinion. Note also
> >> that this change only affects the Python import management commands,
> >> which is a very handy but by no means essential feature.
> >
> > Doing it this way would be an annoyance. Users could have
> > less-than-the-latest Python (or non-CPython version) installed for any
> > number of reasons, and it is not our business to annoy them because of
> > this. Security of using Python is not our concern, it is the user's
> > concern.
> >
> > So I'd prefer that the change probed the support for the -P switch
> > when the relevant Emacs commands/functions are first invoked, and used
> > that if -P is supported, without any annoying messages. Do you see
> > any problems with such an approach?
> >
> > Thanks.
>
> Okay, you are the maintainer, but I hope I explained well that this is a
> security hole.
I'm not sure I understand: if the user doesn't have a version of
Python which supports this option, what else can we do? Refuse to
use such a Python? That doesn't seem to be an option we can use.
Yes, this is a security hole, but it's the user's security hole, not
ours, if the user doesn't install the safer Python.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 15:57:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 70440 <at> debbugs.gnu.org (full text, mbox):
On Fri, 19 Apr 2024 at 18:40, Eli Zaretskii wrote:
> I'm not sure I understand: if the user doesn't have a version of
> Python which supports this option, what else can we do? Refuse to
> use such a Python? That doesn't seem to be an option we can use.
Why not? Let me make sure we're on the same page that this affects only
couple of handy but by no means essential commands that add or remove
import statements. Nobody _needs_ this to write Python code.
> Yes, this is a security hole, but it's the user's security hole, not
> ours, if the user doesn't install the safer Python.
I see it as _my_ security hole, since it was me who added a line to
Emacs that calls 'python -c' in a random directory without removing the
current directory from the module load path (as much as a find it a bad
design choice in Python to do that by default.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 17:32:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: kobarity <at> gmail.com, 70440 <at> debbugs.gnu.org
> Date: Fri, 19 Apr 2024 17:55:51 +0200
>
> On Fri, 19 Apr 2024 at 18:40, Eli Zaretskii wrote:
>
> > I'm not sure I understand: if the user doesn't have a version of
> > Python which supports this option, what else can we do? Refuse to
> > use such a Python? That doesn't seem to be an option we can use.
>
> Why not?
Because it's unthinkable?
> Let me make sure we're on the same page that this affects only
> couple of handy but by no means essential commands that add or remove
> import statements. Nobody _needs_ this to write Python code.
That's not relevant. The important part is that if we accept your
proposal, users who have Python that doesn't support -P will be unable
to invoke Python even if their Python programs don't use the
problematic features.
> > Yes, this is a security hole, but it's the user's security hole, not
> > ours, if the user doesn't install the safer Python.
>
> I see it as _my_ security hole, since it was me who added a line to
> Emacs that calls 'python -c' in a random directory without removing the
> current directory from the module load path (as much as a find it a bad
> design choice in Python to do that by default.)
Sorry, you lost me here. But if there's a way to close the hole
without preventing users to use a subordinate Python, please describe
it in more details.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 18:03:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 70440 <at> debbugs.gnu.org (full text, mbox):
On Fri, 19 Apr 2024 at 20:31, Eli Zaretskii wrote:
>> Let me make sure we're on the same page that this affects only
>> couple of handy but by no means essential commands that add or remove
>> import statements. Nobody _needs_ this to write Python code.
>
> That's not relevant. The important part is that if we accept your
> proposal, users who have Python that doesn't support -P will be unable
> to invoke Python even if their Python programs don't use the
> problematic features.
That's a misunderstanding. My patch only affects the following
commands:
python-sort-imports
python-add-import
python-fix-imports
python-remove-import
python-import-symbol-at-point
There's no change in any customization option or in the way Python is
invoked for any other purpose. Of course it would be unreasonable to
change the way other Python subprocesses are invoked.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 18:18:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: kobarity <at> gmail.com, 70440 <at> debbugs.gnu.org
> Date: Fri, 19 Apr 2024 20:02:16 +0200
>
> On Fri, 19 Apr 2024 at 20:31, Eli Zaretskii wrote:
>
> >> Let me make sure we're on the same page that this affects only
> >> couple of handy but by no means essential commands that add or remove
> >> import statements. Nobody _needs_ this to write Python code.
> >
> > That's not relevant. The important part is that if we accept your
> > proposal, users who have Python that doesn't support -P will be unable
> > to invoke Python even if their Python programs don't use the
> > problematic features.
>
> That's a misunderstanding. My patch only affects the following
> commands:
>
> python-sort-imports
> python-add-import
> python-fix-imports
> python-remove-import
> python-import-symbol-at-point
Affects in what way? AFAIU, with your patch these commands will not
work if Python doesn't support -P. Is that right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 18:31:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 70440 <at> debbugs.gnu.org (full text, mbox):
On Fri, 19 Apr 2024 at 21:17, Eli Zaretskii wrote:
>> That's a misunderstanding. My patch only affects the following
>> commands:
>>
>> python-sort-imports
>> python-add-import
>> python-fix-imports
>> python-remove-import
>> python-import-symbol-at-point
>
> Affects in what way? AFAIU, with your patch these commands will not
> work if Python doesn't support -P. Is that right?
Yes. (And again, that's not a gratuitous choice.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70440
; Package
emacs
.
(Fri, 19 Apr 2024 19:03:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 70440 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: kobarity <at> gmail.com, 70440 <at> debbugs.gnu.org
> Date: Fri, 19 Apr 2024 20:30:27 +0200
>
> On Fri, 19 Apr 2024 at 21:17, Eli Zaretskii wrote:
>
> >> That's a misunderstanding. My patch only affects the following
> >> commands:
> >>
> >> python-sort-imports
> >> python-add-import
> >> python-fix-imports
> >> python-remove-import
> >> python-import-symbol-at-point
> >
> > Affects in what way? AFAIU, with your patch these commands will not
> > work if Python doesn't support -P. Is that right?
>
> Yes.
That's what IMO is unthinkable: we cannot possibly force the user's
hand that much, especially since this used to work before. Users need
to learn about the problem and install a newer Python, and then the
security hole will be gone, at least as far as invoking Python from
Emacs is concerned. The most we can do is urge the users to upgrade
in the NEWS entry where we announce this new feature.
This bug report was last modified 1 year and 59 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.