mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3164] end of python2 #1983
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1983
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rusty-snake on GitHub (Jan 18, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3164
Source: https://en.wikipedia.org/wiki/Python2
Python2 is getting a security risk. Till it's completely dead we should remove
include allow-python2.incfrom every profile where it's not requiered. We could also adddisable-python2.incfor profiles where we can't adddisable-interpreters.inc.List of profile with
include allow-python2.inc:b07ef43)@rusty-snake commented on GitHub (Jan 18, 2020):
youtube-dl: still supporting 2.6 and 2.7
@rusty-snake commented on GitHub (Jan 18, 2020):
meld: no python 2.x support
@reinerh commented on GitHub (Jan 18, 2020):
I think some distributions are still providing security support for Python 2.
The goal is to drop it from the next Debian stable release, but it might not get achieved, depending on how many important applications will not yet be ported by then.
Dropping Python 2 support from firejail will make backporting firejail to older distributions more complicated (e.g. the current Debian stable), as many applications there are still running with Python 2. I'm not sure if it then still makes sense to continue uploading backports. But I'm fine with either way.
Interested in other opinions...
@rusty-snake commented on GitHub (Jan 18, 2020):
For now the focus should be on programs written original in p3 or ported to p3 on the original p2 EOL dated (2015).
I agree with you that programs which are still using p2 on Debian stable (and maybe oldstable) should have a opt-in/opt-out note.
@ghost commented on GitHub (Jan 18, 2020):
What would be the security risk of leaving
include allow-python2.incenabled if it is not installed due to being dead?@rusty-snake commented on GitHub (Jan 18, 2020):
None, but if you have one program depending on python2 …
@ghost commented on GitHub (Jan 18, 2020):
As long as the functionality of the include isn't dropped alltogether just yet I'm fine with removing it by default. Perhaps a new switch in
firejail.configwould be handy:@reinerh commented on GitHub (Jan 18, 2020):
Hm, in my opinion firejail.config is more about core functionality of firejail itself, not so much about stuff that could be achieved with profiles.
I would prefer not to introduce this as a configuration option.
A profile-only way of achieving that could look like this:
Include in every profile that needs python a
allow-python.incinclude, and in this include includeallow-python2.incandallow-python3.inc.And whoever does not want to allow python2 could just remove one line in the python include.
@smitsohu commented on GitHub (Jan 18, 2020):
When Python is started from a running sandbox, it will run with all restrictions of the sandbox. Whether or not there is a broken Python binary on the system, waiting to be executed under the restrictions of a sandbox, should maybe not be the primary concern.
Distributions shipping Python2 along with important software written in Python2 will be around for a very long time. Besides Debian Stretch LTS (June 2022) there are also Ubuntu 18.04 LTS (April 2023) or CentOS 7 (June 2024).
As moving to Python3 is not always straightforward or even possible from a practical perspective, I think there will be a strong motivation to run Python2 scripts/tools inside a sandbox like Firejail.
@Fred-Barclay commented on GitHub (Jan 18, 2020):
I'm with @smitsohu here. I don't think we should remove python2 for at least several more years.
@rusty-snake commented on GitHub (Jan 18, 2020):
To clarify my point: I only want to drop
include allow-python2.incfor profiles from programs without python2 support. Of course we should leave python2 for programs with python2 version in common distros. But some profiles (e.g. gnome-music.profile IIRC) never had python2 support, because they are written after the release of python3.@smitsohu commented on GitHub (Jan 18, 2020):
@rusty-snake Thanks, somehow I misunderstood what was the plan! Sounds good 👍
@ghost commented on GitHub (Jan 19, 2020):
I made a suggestion in https://github.com/netblue30/firejail/pull/3167 to help Arch users that still use meld-gtk2 from the AUR that might wonder why their favo diff GUI is suddenly broken.
@Fred-Barclay commented on GitHub (Jan 19, 2020):
@rusty-snake I misunderstood too then, yeah that makes perfect sense 😄
@Vincent43 commented on GitHub (Jan 19, 2020):
Clearing
allow-python2.incfrom apps that never used python2 make sense - it shouldn't be added there in first place however I think we shouldn't remove it from apps that used python2 in earlier versions for compatibility with older distros.I also don't think that
disable-python2.incwould be valuable because if you already get code execution somewhere then it doesn't matter if your exploit call python2 or python3. Python security matters only for apps that use python themselves.@rusty-snake commented on GitHub (Jan 19, 2020):
IMHO we can remove it when debian (old)stable and Ubuntu LTS have the python3 version of the program.
@Fred-Barclay commented on GitHub (Jan 20, 2020):
@rusty-snake I'd push it out a bit further, when CentOS has the python3 versions.
@rusty-snake commented on GitHub (Jan 20, 2020):
@Fred-Barclay Cent OS (latest) or all supported? CentOS latest (currently 8) should have the python3 version so that we can remove it. But CentOS 6 and 7 have very old versions, for which the firejail master profiles are often not (or no longer) developed or at least not well tested
@Fred-Barclay commented on GitHub (Jan 20, 2020):
@rusty-snake honestly I'd say CentOS 7... EOL is 30 June 2024 which is pretty far out there but not too unreasonable IMHO.
@ghost commented on GitHub (Jan 20, 2020):
Claws-mail just started to drop python2 support for some plugins. As we didn't support these in our profile (my ommission) I added a comment.
@rusty-snake You can add claws-mail to your list here now I suppose.
@ghost commented on GitHub (Jan 21, 2020):
I noticed
display.profileis on the list here. And indeed the profile allows both python2 and python3. Yet I don't see any python dependencies in the imagemagick packages on Arch, Debian and Ubuntu. Debian buster actually has it as /usr/bin/display-im6.q16, so it would be broken there. I wonder, is this profile actually still valuable? It is the only command from the ImageMagick tools we support. Without a description it's doubtful regular firejail users actually know what it does, probably confuse it with the DISPLAY env var, etcetera. There haven't been issue reports against it either. In any case we can safely drop the python support completely IMHO.@rusty-snake commented on GitHub (Feb 21, 2020):
openshot never has python2 support
I'm closing here for now. The most allow-python2.inc includes are still justified.