Your message dated Fri, 4 Sep 2015 16:54:08 +0200
with message-id <[email protected]>
and subject line Re: Bug#798010: [Python-modules-team] Bug#798010: ipython3:
malicious dynamic python3 interpreter lookup via "/usr/bin/env python3" in main
executable
has caused the Debian Bug report #798010,
regarding ipython3: malicious dynamic python3 interpreter lookup via
"/usr/bin/env python3" in main executable
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
798010: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798010
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ipython3
Version: 2.3.0-2
Severity: serious
Justification: Debian Python Policy 2.4.2: Interpreter Location
Dear Maintainer,
the main executable /usr/bin/ipython3 has shebang line 1 "#!/usr/bin/env
python3" and thus uses the first python3 interpreter found in $PATH doing a
dynamic lookup at execution time.
If a local user-space Python environment is coming first in $PATH it will thus
yield the Python3 IPython prompt from user space and not from the system
python. This will result in very puzzling situation and clearly is in violation
of the Debian Python Policy which demands the hardcoded system python binary in
shebang.
See Debian Python Policy 2.4.2 Interpreter location:
https://www.debian.org/doc/packaging-manuals/python-policy/ch-
python.html#s-interpreter_loc
=== quote start
The preferred specification for the Python interpreter is /usr/bin/python or
/usr/bin/pythonX.Y. This ensures that a Debian installation of python is used
and all dependencies on additional python modules are met.
Maintainers should not override the Debian Python interpreter using
/usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
bypasses Debian's dependency checking and makes the package vulnerable to
incomplete local installations of python.
=== quote end
best regards,
Tobias Megies
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ipython3 depends on:
ii python3-decorator 3.4.0-2
ii python3-pkg-resources 5.5.1-1
ii python3-simplegeneric 0.8.1-1
pn python3:any <none>
ipython3 recommends no packages.
Versions of packages ipython3 suggests:
pn ipython3-notebook <none>
pn ipython3-qtconsole <none>
pn python3-zmq <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
On 09/04/2015 03:34 PM, Scott Kitterman wrote:
On Friday, September 04, 2015 02:30:47 PM Tobias Megies wrote:
...
See Debian Python Policy 2.4.2 Interpreter location:
https://www.debian.org/doc/packaging-manuals/python-policy/ch->
python.html#s-interpreter_loc
=== quote start
The preferred specification for the Python interpreter is /usr/bin/python or
/usr/bin/pythonX.Y. This ensures that a Debian installation of python is
used and all dependencies on additional python modules are met.
Maintainers should not override the Debian Python interpreter using
/usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
bypasses Debian's dependency checking and makes the package vulnerable to
incomplete local installations of python.
=== quote end
First, Python policy is not Debian policy, so violating it doesn't
automatically make a serious bug. Second, the policy says preferred and
should quite deliberately as the /usr/bin/env approach is quite common in the
Python world and we do not want to force maintainers to patch large numbers of
packages to avoid it.
Also the choice of env python in IPython is very deliberate. IPython is
a mostly a developer tool where you want to be able to use a non system
python.
E.g. for using system IPython in a virtualenv with --system-site-packages.
While you can nowadays also achieve the same effect via python -mIPython
I don't think the drawbacks of the common practice env python is worth a
change. Thus I am closing the issue.
--- End Message ---
_______________________________________________
Python-modules-team mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
