Remove unsafe python2 and webkitgtk1

[corecontingency]

We should seriously consider removing these unsafe and insecure dependencies. This is even more critical when considering that the GIMP flatpak isn't sandboxed, since it uses --filesystem=host.

WebKitGTK 1 is used in the help browser, but has not been supported since 2016, and has dozens of CVEs against it. Without WebKitGTK 1, opening GIMP help will just open up a link to the help pages with the default browser, which in my IMAO is a fine trade-off in the name of security.

Most every single distro has already removed WebKitGTK 1 as a GIMP dependency, i.e. see debian stable.

Python 2 is EOL as of January 1, 2020, and is no longer receiving security updates. Obviously Arch has already removed python2 as a GIMP dependency, but even conservative distros are already removing python2. Both the debian unstable and debian testing GIMP packages no longer use python2 as a dependency.

I would be happy to submit a pull request to remove both of these dependencies, but I wanted to get some feedback and thoughts first.

[Jehan]

Until now I have been backing away from deprecating these parts of GIMP in the flatpak because it's nicer to have a full-featured GIMP, and also because I am always hoping we will be releasing GIMP 3 soon enough to not have a feature-gap span. But I am starting to agree, at least about the Webkit part. As you say, opening help pages in the browser is an acceptable trade-off. This being said, Webkit is also used for the webpage plug-in (basically taking full screenshots of web pages) and there is no replacement for this in GIMP, though nowadays browser are starting to get this feature built-in (Firefox has it at least). So I don't know, maybe I guess. Also webkit is a real horror to build, but that's just a side note. 😛

I'll want to discuss with others of the GIMP team to gather their opinions first, though.

As for Python, I think it is much too early to drop it. It just got deprecated and a flatpak is the right place to get it back. Also scripts in Python are very much used and useful so dropping the support will make a lot of people angry! I think we should stick with Python2 until GIMP 3 is out.

[TingPing]

Also Python 2 will continue to get out of tree security fixes from companies like Red Hat for a short while. WebKit 1 is totally dead though.

[TheEvilSkeleton]

We should seriously consider removing these unsafe and insecure dependencies. This is even more critical when considering that the GIMP flatpak isn't sandboxed, since it uses --filesystem=host.

Would it be okay to at least harden the sandboxing by only permitting xdg-downloads xdg-pictures? I honestly don't understand why filesystem=host has been applied when it can be much more restrictive without really sacrificing convenience

EDIT: I'm guessing filesystem=host is applied to pick up the fonts located at /usr/share/fonts?

[Erick555]

filesystem=host is most often used for removable media access.

[Jehan]

Would it be okay to at least harden the sandboxing by only permitting xdg-downloads xdg-pictures?

GIMP is not a toy software which you use once in a while and just needs access to a few standard directories. In our case for instance (animation studio, ZeMarmot project), an artist uses it daily, professionally, 5 days a week, all year long, on hundreds of files, well organized by projects in various directories (not standard $XDG_PICTURES_DIR directories). We can't just diminish its usage to a few directories. It would make no sense. Of course, you can always move files back and forth but that is not a sane workflow; it's as if my text editor could only edit files from $XDG_DOCUMENTS_DIR and every time I needed to edit code in GIMP (which I personally do also daily, 5 days a week, all year long, etc.), I had to move files back and forth. Let me tell you that I would have stopped using this editor a long time ago if I had to do this! 🤣

Basically it would make the GIMP flatpak technically useless. So nope, that is not possible. Sorry! 😛

The only way we will be able to harden file access will be when we will be able to use the portal, which means with the GTK+ 3 port. And probably not even exactly for GIMP 3.0 (but after) because we have things to figure out first (as we tweak the import/export dialogs, and were even planning to do more tweaking — still because GIMP requires advanced file usage — which won't be possible with the portal; I have been thinking of a redesign of the export dialog to allow us to use the portal while not losing features; but not sure when this will happen).

Still I would like to say that the GIMP flatpak is not more unsafe (and not safer either indeed) than common distribution packages as have been used on Linux for dozens of years. And this flatpak is upstream-managed (so if you don't trust us as packagers, you should not use GIMP at all as we are also the developers! 😆). Now I'm not saying we don't want to harden the flatpak. Improving usage safety and transparency of the builds is something I have been working on for a few years now. Just that it will take some time and that in the meantime, it's not worse than before anyway. In any case, diminishing GIMP abilities is not the way to go. 😉

[TheEvilSkeleton]

Amazing writeup! Anyway, I understand why it's important.

After all, if you don't like its permissions, you can always overwrite them

[xanscale]

imho --filesystem=home seams a good compromise