end of python2

[rusty-snake]

The Python 2 language, i.e. Python 2.7.x, was officially discontinued on January 1, 2020 (first planned for 2015) after which security patches and other improvements will not be released for it. With Python 2's end-of-life, only Python 3.5.x and later are supported.

Source: https://en.wikipedia.org/wiki/Python2

Python2 is getting a security risk. Till it's completely dead we should remove include allow-python2.inc from every profile where it's not requiered. We could also add disable-python2.inc for profiles where we can't add disable-interpreters.inc.

List of profile with include allow-python2.inc:

• anki.profile
• arm.profile
• autokey-common.profile
• bleachbit.profile
• blender.profile
• caja.profile
• cameramonitor.profile
• catfish.profile
• celluloid.profile
• cherrytree.profile
• ddgtk.profile
• deluge.profile
• d-feet.profile
• dia.profile
• display.profile
• electrum.profile
• exfalso.profile
• filezilla.profile
• flowblade.profile
• fontforge.profile
• font-manager.profile
• freecad.profile
• gconf.profile
• gnome-music.profile
• gnome-schedule.profile
• hexchat.profile
• inkscape.profile
• klatexformula.profile
• kodi.profile
• krita.profile
• liferea.profile
• lollypop.profile
• macrofusion.profile
• meld.profile (b07ef43)
• mendeleydesktop.profile
• mpDris2.profile
• mpsyt.profile
• mpv.profile
• ms-office.profile
• mypaint.profile
• natron.profile
• nautilus.profile
• nemo.profile
• nitroshare.profile
• nyx.profile
• obs.profile
• openshot.profile
• picard.profile
• pithos.profile
• pitivi.profile
• playonlinux.profile
• profanity.profile
• pybitmessage.profile
• qbittorrent.profile
• qutebrowser.profile
• ranger.profile
• rhythmbox.profile
• scribus.profile
• sdat2img.profile
• smplayer.profile
• soundconverter.profile
• subdownloader.profile
• xpra.profile
• youtube-dl.profile

[rusty-snake]

youtube-dl: still supporting 2.6 and 2.7

• Drop python 2.6 support ytdl-org/youtube-dl#5697
• https://github.com/ytdl-org/youtube-dl/blob/master/.travis.yml

[rusty-snake]

meld: no python 2.x support

• https://gitlab.gnome.org/GNOME/meld/blob/master/NEWS
• https://gitlab.gnome.org/GNOME/meld/blob/master/.gitlab-ci.yml
• https://gitlab.gnome.org/GNOME/meld/blob/master/README.md

[reinerh]

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]

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.

[glitsj16]

What would be the security risk of leaving include allow-python2.inc enabled if it is not installed due to being dead?

[rusty-snake]

None, but if you have one program depending on python2 …

[glitsj16]

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.config would be handy:

# Enable or disable support for Python 2, default disabled.
# allow-python2 no

[reinerh]

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.inc include, and in this include include allow-python2.inc and allow-python3.inc.
And whoever does not want to allow python2 could just remove one line in the python include.

[smitsohu]

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]

I'm with @smitsohu here. I don't think we should remove python2 for at least several more years.

[rusty-snake]

To clarify my point: I only want to drop include allow-python2.inc for 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]

@rusty-snake Thanks, somehow I misunderstood what was the plan! Sounds good 👍

[glitsj16]

I made a suggestion in #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]

@rusty-snake I misunderstood too then, yeah that makes perfect sense 😄

[Vincent43]

Clearing allow-python2.inc from 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.inc would 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]

however I think we shouldn't remove it from apps that used python2 in earlier versions for compatibility with older distros.

IMHO we can remove it when debian (old)stable and Ubuntu LTS have the python3 version of the program.

[Fred-Barclay]

@rusty-snake I'd push it out a bit further, when CentOS has the python3 versions.

[rusty-snake]

@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]

@rusty-snake honestly I'd say CentOS 7... EOL is 30 June 2024 which is pretty far out there but not too unreasonable IMHO.

[glitsj16]

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.

[glitsj16]

I noticed display.profile is 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]

openshot never has python2 support

---

I'm closing here for now. The most allow-python2.inc includes are still justified.