search

Beep6581 / RawTherapee

A powerful cross-platform raw photo processing program
https://rawtherapee.com
GNU General Public License v3.0
2.79k stars 316 forks source link

Flatpack version won't allow use of secondary drives #6314

Open chgruver opened 3 years ago

chgruver commented 3 years ago

Short description

I have a dual boot system Windows and some form of Linux (currently Mint 20.2) I also have a partition that I share between both OSes. The problem is when loading RawTherapee from a flatpak it shows the shared partition but I am unable to access it. If I install the non flatpak version from the repositories (these apps are not always the most recent version especially on Mint) it will work

Steps to reproduce Provide the necessary steps to reproduce the issue.

  1. Install Flatpak of RawTherapee
  2. Make sure to have a primary hdd/ssd and a secondary hdd/ssd
  3. Open RawTherapee
  4. Try to access secondary drive

Expected behavior

To be able to access pictures stored on secondary drive.

Additional information Some essentials:

Lawrence37 commented 3 years ago

Have you configured Flatpak to give RawTherapee permission to access the partiton?

Benitoite commented 3 years ago

How did you install the flatpak? Flatpaks are typically sandboxed by default. If we know the source, we might be able to request a config change.

chgruver commented 3 years ago

I installed the flatpak via the command line method shown on flathub.org for RawTherapee

Benitoite commented 3 years ago

https://github.com/flathub/flathub/pull/789/commits/511032cbf0dcda9765a74766e97d0f58e8b245a6 ~ Filesystem Access should be set to host to access /mnt ~ Needs updating to 5.8 ~ The flatpak was pulled from @scx ~ @paperdigits has some RT flatpak experience to bear.

paperdigits commented 3 years ago

I can make a PR for 5.8, as that is relatively straight forward.

You can use flatpak's cli interface or an app called FlatSeal, available from flathub, to adjust the permissions of your flatpak. Apps from flathub try to ship with a minimum of permissions and are supposed to be tweaked by the end user.

Also note that you can open issues against the flatpak itself.

paperdigits commented 3 years ago

@Benitoite the flatpak is at version 5.8

Benitoite commented 3 years ago

@paperdigits I recall this issue being raised a few years back also. Thanks for looking into that, I have zero experience with flatpak besides these issues. Looking at flathub/flathub, I am having trouble seeing the actual repository, or don't understand the flathub structure well enough to locate the com.rawtherapee.RawTherapee... file, to reference.

paperdigits commented 3 years ago

No problem. The repo is here: https://github.com/flathub/com.rawtherapee.RawTherapee

Let me know if you have more questions.

On July 29, 2021 3:59:00 PM PDT, Benitoite @.> wrote: @. I recall this issue being raised a few years back also.

Thanks for looking into that, I have zero experience with flatpak besides these issues. Looking at flathub/flathub, I am having trouble seeing the actual repository, or don't understand the flathub structure well enough to locate the com.rawtherapee.RawTherapee... file, to reference.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/Beep6581/RawTherapee/issues/6314#issuecomment-889513008

scx commented 3 years ago

@chgruver @Benitoite @Beep6581

Flatpack version won't allow use of secondary drives

Well, according to the Flathub members, it's not a bug, it's a feature. I always try to give the --filesystem=host permissions, because users expect it. Unfortunately, Flathub members have a different opinion on this matter. They always want to limit application permissions as much as possible, at least officially. Anyway, I got at least several dozen requests (both on GitHub and IRC channel) to remove the --filesystem=host permissions from my packages. This was also the case with RawTherapee. As you can see, my standalone package has full permissions, but I was forbidden to give the same permissions on Flathub. I know that at least some of you are familiar with the flatkill website. It is true that most popular software on Flathub have the highest possible access to the filesystem. I tried to confront Flathub members why new applications cannot have such permissions. The answer was as follows: "rules are fluid and just because something has been accepted before doesn't mean it would be now". Moreover, for already existing packages, "patches are welcomed". It was in 2018. Even today, GIMP, LibreOffice, VLC, etc. still have the highest permissions. Moreover, new submissions are still accepted with highest privileges. For example, Gimpsle was accepted with the --filesystem=host access, although yet in 2018 they said that even GIMP should have lower permissions. I will tell you one thing: these rules are bullshit. They are not there to provide exemplary quality, but to discriminate one software against another. It doesn't matter if the software is full-value or half-working (generally speaking, almost every IDE on Flathub is broken, including Visual Studio Code, Code::Blocks, JetBrains IDEs, etc.), polished or bugged, stable or unstable, safe or with security holes (we already have packages that have literally over 100 known security vulnerabilities (already marked with CVE) and no one has done anything about it for years). The only thing that matters is who creates the application and who is the maintainer of the package. If you are a GNOME member, you can do anything, break all the rules. If you have ever criticized GNOME or Flatpak in public, you will be discriminated. This is software fascism. The hierarchy goes something like this:

I will give you a few examples:

Permissions

As of Jan 1, 2020, at least these applications have the --filesystem=host access:

We have similar amount of applications with the --filesystem=home access.

From a security perspective, there is not much difference between the --filesystem=host and --filesystem=home. They both allow you to escape from the sandbox. So, for example, if you have an application without direct access to any devices and without network access, but with at least --filesystem=home, you can still use a camera, take a picture of the user and send it over the Internet. By the way, Snap doesn't have this problem at all (see: snap's home, as well as personal-files, removable-media, etc.), but you can't say something was better done by Canonical, because that would be "hate". Oh, and we have the same security problem with the --talk-name=org.freedesktop.Flatpak permission. In Snap, this problem was partially resolved by the slots. However, it is not suitable for every application. This is why Canonical provided the classic confinement. Unfortunately, the snapd packages for Fedora are intentionally broken to prevent such applications from running. It is easy fixable in classic Fedora (all you have to do is create a symlink... with root permissions), but not in Silverblue.

Anyway, the flatpak sandbox is mostly a lie. Let's say you want to provide the fully sandboxed game. You give it standard permissions, but without filesystem access, apart from its own directory. Then you provide access to the Internet and joystick. You think it is pretty safe, but it is not, because it can actually access your secret data and sent it over the Internet. It is because the whole permission system is broken. If you want to add access to the joystick, you must also give access to the camera... as well as the whole /dev/. If you want to add access to the scanners, you have to provide access to the Internet! Makes sense? In the end, in typical scenario, flatpak doesn't protect you from anything. There is no such problem in Android, but on the desktop, a lot of portals are missing. Let's talk about scanning.

Currently, to access the scanner under flatpak you need to build libusb, then sane, then its backends. Each of them requires a lot of patches, which makes it almost unmaintainable. And you still have to add various permissions, including some DBus access (e.g. --system-talk-name=org.freedesktop.Avahi) and Internet access (yes, there is no way to limit network access to the local network). And it still won't work in all cases, because there is no way to provide udev rules. Even if it were possible, each distro has its own udev rules, e.g. because they use different groups. For example, lp (because of All-in-One devices), saned, scanner, etc. We have similar problems with the joysticks/gamepads, recent files, etc. Flatpak doesn't provide half of the APIs needed for full-fledged applications, but Flathub members still blame developers for half-working software. For example, according to the Flathub members, to access files, you should use the file chooser portal (BTW: it is only available for Gtk+3 and Qt5 apps, but according to the Flathub members, it is just an API, so you could implement it e.g. in Gtk+2, and then provide and push updates for Ubuntu, Fedora, Endless OS, Chrome OS, Red Hat Enterprise Linux, Linux Mint, openSUSE, Arch, Debian, CentOS, Gentoo, Kubuntu, Solus, Alpine, Megeia, Pop! OS, elementary OS, Raspberry Pi OS, Clear Linux, Void Linux, NixOS, PureOS, SulinOS, Ataraxia Linux, Zorin OS, Deepin, Pardus and Pisi GNU/Linux - it is so simple!). However, it just gives you access to a single file. This works in very few cases. Most of the time it will be useless:

Anyway, as of Jan 2020, GIMP can have the highest filesystem access, and Pinta must be limited to the standard folders (Documents, Pictures, etc). Lollypop and VCL may have the --filesystem=host permission, independent music player can't. Darktable is allowed to use such permissions, RawTherapee it not. Why? Because Flathub/GNOME members say so. To be honest, it is even more ridiculous than you can imagine. For example, GPick is supposed to read and save the color pallets. According to the GNOME/Flathub developers, such files are just like JPEG images, so they should be saved in the Pictures folder: "I'd prefer to see it limited to xdg-pictures. It's easy for users to change it themselves." (so the app wouldn't even have access to the Documents!). Personally, I don't know any graphic designer who does that. The --filesystem=host permission on Flathub is officially banned at least since 2018, but Glimpse was accepted with the highest filesystem permission year later without any problem! However, we can access GIMP from Rawtherapee, but it doesn't work for Glimpse (try to use a custom editor in RawTherapee: flatpak-spawn --host flatpak run "org.glimpse_editor.Glimpse" - technically, it would be possible - it is a permission problem). Why? Because GIMP is GNOME software, and Glimpse is not - it is just a fork.

What are the advantages of using a --filesystem=host over --filesystem=home?

If you only care about removable media, the --filesystem=/run/media permissions may be enough.

Additional, users often expect access to GVfs (--filesystem=xdg-run/gvfs:ro, --talk-name=org.gtk.vfs, --talk-name=org.gtk.vfs.*), e.g. for Android files (MTP).

In a normal store, the developer/maintainer decides about the default permissions. But as you can see, Flathub is not a normal store. It never was.

AppData

For a long time (since Dec 2018), every application on Flathub has to provide an OARS rating. While it might make sense for games and gambling apps, it doesn't make sense elsewhere. For example, every package manager/software store client must report all application features that are available there. So, according to the AppData, the Steam client is mostly about "prostitution" and "slavery". Did I say that every Store app must follow these rules? Well, there is one exception - GNOME Software. It doesn't have to report anything like that! However, since the flatpak package of Steam client is maintained by the Freedesktop runtime (basically, Flathub runtime) member, it can lie about telemetry. So, again, according to the AppData, there is no telemetry at all! No update checking! No Steam Hardware & Software Survey! No crash dumps. Nothing at all! However, if you are an independent developer, you must report the mild level of telemetry only if you have optional update checker, and moderate level if your app may collect statistical data, even if it is disabled by default. Still not enough? Ok, listen this. The flatpak package of GIMP claims that it provides the gimp binary. The AppData specification makes it clear - it must be "installed into a location in PATH". However, flatpak doesn't export any binaries to the host. Snap has this capability, and what's more, it can export multiple binaries from a single package. This feature is often used by developers/maintainers. Yet another advantage of snap over flatpak. But lack of this feature in flatpak is one thing (they are "working" on it since 2018), and lying in the AppDate file is another thing. I proposed to automatically remove such entries from AppData files by flatpak-builder. We already have a similar fix for TryExec in desktop files. However, my request was ignored as "unnecessary". Last but not least: GIMP claims that it uses a modern toolkit. What is modern toolkit? According to GNOME (kudos is a GNOME thing - AppData extension used by GNOME Software to promote modern software, and it acts as a kind of "awesomeness score"), ModernToolkit is "like Gtk-3 or QT-5". But we already know that GIMP 2.x uses Gtk+2. Is it modern? Unfortunately, not. It doesn't support Portal APIs (e.g. native file chooser dialog), Wayland, HiDPI, transparency, etc. It doesn't even have currently supported web control. There was WebKitGTK, but it was banned in Fedora several years ago (in Fedora 27, released in 2017), because of "roughly 150 unfixed security vulnerabilities". However, this absolutely doesn't prevent anyone from using this component on Flathub. Actually, GIMP still uses it in 2021. Should I mention that webkitgtk 2.4.11 was released in 2016, and has not received any security patches since then? Anyway, what is the penalty for lying in kudos? According to GNOME, "any application that is found cheating, i.e. adding kudos artificially will have all the kudos manually removed with a blocklist rule in the AppStream builder". But when it comes to GIMP, of course it won't happen, because it's still GNOME Software, even if it sticks to Gtk+2 and doesn't meet the GNOME3 HIG criteria at all.

README

Providing the README is banned on Flathub at least since 2018. Of course, many apps still do this. As of Jan 2020, it is over 100 packages, including Adobe Flash Player, some GNOME software (e.g. Contacts, Déjà Dup Backups, D-Feet. Font Viewer), HandBrake, JetBrains IDEs, Lutris, NetBeans, OBS Studio, Remmina, RetroArch, Skype, Slack, Steam, Thunderbird, VueScan, WPS Office. Some of these files are completely pointless. However, even if they are desirable, they should be removed: "No user is going to find this README to read your FAQ. If you consider any of this critical, put it in appdata." So, why not put this in your AppData file? Because it is too limited to handle complex FAQ. The appstream-glib puts various restrictions on line length, header length, number of paragraphs, number of characters, etc. These rules change even several times a year. Nobody has time to edit it all the time. If the AppData file fails validation, the entire build is rejected. Theoretically, you can validate it before submitting commit (however, don't assume that Flathub has provides the latest version like it should, because it isn't always the case), but we often use some preprocessor to generate full AppData file, so it isn't available at pre-build time. Is isn't also upstreamable, because we are talking about flatpak-specific issues. Besides, it would require manually generating patches with each update, which make it almost unmaintainable. And as I said, the AppData summary has a length limit. So, why not put a link in the AppData file? Because you can't. Not only it won't be formatted as link, but the entire file will also fail validation. All links, even provided as plain text, are explicitly prohibited.

Manifest layout

According to the Flathub members, you should put your manifest in the single file, and all additional files (e.g. patches) should be placed in the main directory. In my opinion, it is the maintainer who should decide what is more convenient for him, not the reviewer who will never add a single commit after the review is done. This is obvious on Snapcraft, but not on Flathub. However, even here we have a lot of examples of breaking this rule:

According to the Flathub maintainers, splitting manifest over files is type of "code obfuscation". BTW, since Freedesktop 18.08, they put each module in separate file. The same is true for GNOME 3.30 and later. Anyway, why do this at all? Because it is easier to maintain such code. For example, if you have a lot of pure Python modules (without native deps), you can relatively easily (well, it is not always that easy) generate manifest for each of them (e.g. by flatpak-pip-generator, flatpak-pip-generator + flatpak-json2yaml, or similar tool). In the end, you can automate it with a simple script. However, if you absolutely want to use just single file, you will have to manually copy-paste everything each time. It is really waste of time, and often leads to mistakes. Actually, I've created tools to update components (general-type, not only for python modules), beautify the code, add the necessary tags and validation (e.g. suggest to replace buildsystem: cmake with buildsystem: cmake-ninja, add builddir: true and config-opts: [DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo] to both of them, update config.{sub,guess} and perform autoreconf for buildsystem: autotools, add --disable-static, --enable-maintainer-mode and maybe even --disable-manpages to config-opts: when possible, replace "http:" with "https:" in url: when possible, etc.), etc. They actually work pretty well, but only for single-module manifests (it means that each module must be placed in a separate file). Moreover, when you have single-module manifest, you can easily compare them between various projects. So, for example, wxWidgets/wxGTK is typically built with project specific options (some applications work better with wxWidgets 3.0, others with 3.1, some programs work better with Gtk+2, others with Gtk+3, some need web control, others don't, each wxWidgets variant may require different patches, etc.) , but it's still nice to be able to compare manifests side by side. What's more, in this way it's easier to manage dependencies, because you can see what belongs to what, which is important when updating the program, runtime or shared-modules, and there is a need to remove unnecessary components.

Helper scripts

Most people will agree that it is easier to run ./build.sh than e.g. git submodule init; git submodule update; flatpak-builder "build" "io.github.wxmaxima_developers.wxMaxima.yaml" --force-clean --install-deps-from="flathub" or similar command. This is especially important when you are working with the vendor who is not very familiar with flatpak. Of course, this is not limited to the build script. For example, it's much easier to update python modules with a simple script than doing it manually. It is obvious to everyone, except to Flathub members. Such helper scripts are explicitly forbidden. And because it is strictly forbidden practice at least since 2018, a lot of projects can still use it, e.g.:

Upstream needs to be involved

According to Flathub members, "upstream needs to be involved". We can safety assume that every package that use extra-data is maintained beyond the knowledge and consent of the upstream vendor. As of Jan 1, 2020, it includes Android Studio, Dropbox Client, GitKraken, JetBrain IDEs, Minecraft, Skype, Slacks, Spotify, Sublime Merge, Sublime Text, Teams, TeamSpeak, UnityHub, Viber, Visual Studio Code, VueScan, WPS Office, Zoom and dozens of other packages. All of them should be removed from Flathub immediately.

On the other hand, Flathub members like to make false claims that the vendor is not involved when he (or she) really is. It was the case with Qalculate. My application submission was blocked for no reason. Outside Flathub, I have already worked with Hanna Knutsson (the upstream vendor) on the flatpak package. She forked my repo, has provided some pull requests, and even started to ship self-contained packages with her GitHub releases. It was Jan 20, 2020. I asked Flathub members one more time about my applications submissions, showing them that TUV is really involved and waiting for merging this repo. Flathub members reserve the right to decline any package as they wish, as you can always host your own flatpack repo. However, they get furious every time when a popular app does this. This was the case with Qalculate. Just 4 days later, they finally put a review... with fake issues. They stated that vendor is not involved or the app is no longer developed (remember, just 4 days earlier the new release has been shipped with a standalone flatpak package, and they knew about it). They also claim that there are pointless README, license files, shell scripts and too wide permissions (e.g. --filesystem=home). It was a lie. There was no shell script, README, license files, and the filesystem access was actually limited to --filesystem=xdg-documents, --filesystem=xdg-desktop and --filesystem=xdg-public-share. What is more, at the same day, they put the same review with fake issues in almost my every app submission, for example:

So, for example, the author of Imagine is waiting for accepting his application at least since 2019. Flathub maintainers know about it (I reminded them about it several times on the official IRC channel), but still claim that there is "no upstream participation". We have exactly the same case with mtPaint. Yet in 2018, the author stated that he is "quite interested", but according to the Flathub maintainers, he is not. Another example: gImageReader. When it comes to NaSC, I even provided quite a lot of pull requests to gain some so-called "bonus points": changing the Application ID, using XDG user directories, improving the AppData file, porting to Meson, etc. My patches were mostly accepted, but Flathub maintainers still claims that there is "no upstream participation". I could give you even more examples, but this is not the place for that. At first, I wanted to reply, but then I asked myself: how should I respond to fake issues? They weren't made by a mistake. It was clearly intentional. When they stared removing my comments, I just gave up. It was the case with XSane. As I stated before, to gain scanner access in flatpak, you have to build libusb, then sane, then additional sane-backends, e.g. hpaio (a scanner portal has been already proposed, but there has been no progress since 2017). When it comes to hpaio, it is really buggy and requires a lot of patches just for flatpak. What is worse, there is no way to make them upstream (vendor does not accept PRs/MRs). Anyway, since version 3.19.1 (released in Jan 2019), at least dozens of drivers are broken. HP knows about it, but they just didn't care about old device models. Several distributions decided to prepare their own patches to restore support for these devices. I took the patch from Fedora and extended it to all affected models, then limited it to only those devices that actually can scan. I did all of this for OCRFeeder, after several people reported problems on GitHub, GitLab, and a few others via emails. But of course, these issues are not related to OCRFeeder itself, but to HPAIO. So when I was submitting XSane for Flathub (to improve scanning support in Flatpak packages), I just linked these issues, to make it clear, why such patches are needed. What did the members of Flathub do? They removed comments ("flathub deleted a comment from scx on Jan 26, 2020") with these links (please note that there is still an evidence about it: "mentioned this pull request on Jan 26"), and then in the review they stated: "I doubt these patches are relevant to flatpaked xsane" and: "Please say upfront if you're going to address issues in your submission so we don't waste time arguing". Of course, all these patches were already approved in OCRFeeder, and no one said a bad word about them. But OCRFeeder is GNOME software, and XSane is not. Anyway, it was another level of trolling that I couldn't handle anymore. I gave them an ultimatum: Either they stop their software fascist practices or I won't longer provide even a single commit for any Flathub package, including these ones that have already been accepted. There was no reply for this. Since then, some of my packages have been already broken, intentionally or not. It is clear to me that I am not welcome there, and that whatever I do, it won't be accepted. This is revenge for that I publicly criticized Flatpak and Flathub in 2018-2020.

Flathub maintainers claim that they "want to be seen as source of good practices", but in the end, most packages don't meet Flathub's rules. And if you also take runtimes into account, then there is no even one application that would meet these rules. Even besides these so-called "issues", a lot of packages are half-working software, often buggy and unstable, and what is worse, with tons of security holes. Each Freedesktop runtime version brings more bugs and issues than Debian, Ubuntu or even Fedora. For example, in Freedesktop 1.6 there was a critical bug in glibc (we hit this bug in PyQt apps, e.g. ReText) and SDL2 (we ran into this in Widelands). In GNOME 3.30 the help system was broken (Gtk+ apps were affected, including OCRFeeder). In KDE 5.11, Qt was completely broken on EL7. In Freedesktop 19.08, Mesa was broken on some configurations (Widelands on EL7 was affected by it). In the same runtime, pciutils was broken. While this was fixed relatively quickly in the Freedesktop runtime, we had to wait a few months to backport this fix to the GNOME runtime.

There are a lot of flatpak-specific issues when it comes to:

What is worse, Red Hat/GNOME/Flathub members keep suggesting you to solve problems in the most ridiculous ways:

The desktop environment is super complex. Is is not a server with a docker, where all you need is access to files, network and a few other things. No, it's much more. Flathub/GNOME members would like to develop it at a low cost, but it doesn't work that way. Unfortunately, it seems they just couldn't handle this properly. Flatpak was supposed to solve Linux problem. However, it isn't a magic cure for Linux itches. In the end, it is introducing more problems than it is solving.

Maintaining flatpak applications is really pain in the ass, not only because of above issues, but also because you need to build tons of components (and their dependencies) from scratch. This includes: Avahi, Boost, codecs, doxygen, fonts (in bundled fonts we have colored emoticons, but not math symbols or CJK chars), freeglut, Haskell modules, hpaio, ghostscript, GNU Plot, GraphicsMagick, graphviz, Gtkmm, gtk-sharp, GtkSharp, ImageMagick, libusb, Lisp (e.g. CLISP, ECL, GCL, SBCL), netpbm, net-snmp, nodejs, OpenAL, OpenCL, Perl modules, Python modules, Ruby modules, sane, wxWidgets/wxGTK and literally hundreds of other components. A lot of them require extensive patching, which is usually the responsibility of the distribution maintainers (unfortunately, for many Linux components the upstream is already dead, so they are maintained by Canonical/Debian/Red Hat/SUSE employees/maintainers). Here, you have to keep maintaining everything that isn't included in the minimalist runtime (which is not minimal when it comes to size, but just focused on GNOME stuff) by yourself. This is why packages are often extremely outdated and insecure (especially when it comes to FFmpeg, Ghostscript, OpenJPEG, Python modules, WebKit, etc.). BTW, in Snap, you can just re-use existing DEB packages. This approach has another advantage - the developer can be informed about component updates, especially in the case of security patches. Moreover, Flathub SDKs (Freedesktop, GNOME, KDE) lack of standard build tools, such us ImageMagick/GraphicsMagick (to resize icons - there is only rsvg-convert, but for obvious reasons, it cannot handle raster icons), dos2unix (to convert line endings in plain text files), XMLStarlet (to modify XML files, e.g. the AppData file), jq (to handle JSON files), etc. You have to build all of them by yourself! In Freedesktop 19.09, even intltool was removed, although it was recommend tool to handle translations of e.g. AppData files!

There is still no clear information on which runtimes are fully supported and by when. It is especially confusing with GNOME. Maintenance is abandoned almost immediately after a new version is released. Occasionally there are some patches, but it isn't known whether they are intended to fix all security bugs or just selected ones. Anyway, the first one wasn't always the case. Finally, after a maximum of two years (when the base runtime becomes EOL, which is Freedesktop), they are marked with EOL as well, but in fact the status is unknown for about 0.5-1.5 years. Freedesktop runtimes should be supported for 2 years, but that's not entirely true. First of all, even fully supported runtimes may provide insecure components for months. It was the case with GNOME 3.36 - for long time, it had FFmpeg 4.2.1 with no security patches backported (CVE-2020-12284). But there is much bigger problem. You see, if your application uses some libraries available in flatpak shared modules, you must use those modules. Otherwise you would break Flathub rules (which is extremely stupid: for example, Qt4 is provided without SVG support - why? is there any security hole in it? no, it's just because Qt4-based apps don't deserve to open SVG files!). And since there are GLU, GLEW, Gtk+2, libappindicator, libsecret, libusb, Lua Python2, Qt4, etc., shared modules are used very often. Unfortunately, these modules are often only compatible with the latest runtime. So, for example, GIMP had to revert shared-modules to older version, because Gtk+2 was broken in GNOME 3.32. And because of this, for several months they couldn't apply security patches for Python2 (sorry, you couldn't use multiple versions of shared-modules in single project, because your manifest must be "clean"). You can say it was an incident. Unfortunately, this is more a rule than an exception: "This change will intentinally break manifests of apps that used udev from shared-modules. The assumption is that app using freedesktop 18.08 runtime won't need updating shared-modules and if they do then it's always recommended to switch to 19.08". Unfortunately, often you can't just switch to a new runtime, due to incompatibility with new GCC toolchain, some libraries (e.g. ICU), GNOME stacks, etc. Of course, it may be doable, but usually takes some time. There is one more reason - new runtime runs are often heavily bugged, and corrections can take long months, sometimes even over half a year (e.g. pciutils in GNOME 3.34, if I good remember) - if they are introduced at all, which does not always happen (e.g. glibc bug in Freedesktop 1.6). There is one more thing about shared modules worth to mention - Flathub members treat this like their own working directory. As I said before, intltool is a kind of Linux standard, and it was removed in Freedesktop 19.08. Of course, this move had negative consequences. Since a lot of Linux components actually require intltool and flatpak-builder at the time did not allow the same module to be built multiple times (this was changed later at my request), many shared modules had problems with building. They kept adding and removing references to intltool from manifests, thereby repairing the packages they needed at the moment and breaking others. Of course, the other package maintainers on Flathub didn't have such privileges, so they had to wait weeks or maybe even months for the module they needed to be fixed. During that time, they couldn't apply security patches. Anyway, these are some of the reasons why Flathub applications often use unpatched and insecure versions of components like Gtk+2, OpenJPEG, Python2, udev, etc. Do you know what is the Flathub members response to these allegations? I will tell you: "Sorry, but no". They prefer to pull the wool over people's eyes (BTW: do you remember 10% market-share by 2010 and 20% market-share by 2020?), and at the same time discredit the Snap/Snapcraft that objectively provides a better level of security. And believe me, they really hate Snap. Canonical has had problems with GNOME from the very beginning, when they started submitting patches to GNOME 2. Many of them were rejected for biased reasons. GNOME members have always ignored the needs of users, maintainers, and developers. This is why Canonical decided to develop Unity and later Mir (and others forked GNOME2/GNOME3, or patched Gtk+3). However, development costs money, they had a budget at least 10 times smaller than Red Hat, and it is hard to make big cash on the Linux desktop. Therefore, they had to revise their plans and focus on the cloud and IoT. Personally, I think the Snap/Snapcraft is doing pretty well for the resources that Canonical could have been spent on it, but unfortunately it is still far from being perfect.

Flathub/GNOME members are always externally rude:

They treat any form of criticism as "passive-aggressive behavior", but on the other hand, they see nothing wrong with calling the flatkill website owner an idiot.

What is even worse, they started spreading some ridiculous rumors. For example, when Visual Studio Code team launched their snap package and stated that they are not going to provide or even support flatpak, some GNOME and flatpak evangelists tried to discredit Snap and VSC, by saying that Canonical is sleeping with Microsoft. The reasons for choosing snap were purely technical - such package is a full-fledged IDE, while flatpak package is just broken by design. However, Flathub members state that the VSC is broken, not the flatpak. We had the same situation with the Atom:

<Persi> A big chunk of the issues that we get on io.atom.Atom follow the formula "In installed $PLUGIN and it doesn't work, but it works on snap/deb/rpm"
<Persi> We keep telling them to use flatpak-spawn --host, but that isn't going to be a big help to users on more rigid systems like silverblue or endless
<TingPing> Persi, gnome-builder did everything right, so copy that

They know it can't work that way, because plugins can't really provide native dependencies or use existing deps from the host, but they will still claim that all IDEs on the world are broken, except GNOME Builder of course, which is supposed to handle building flatpaks and only flatpaks. Another example: Flathub took JetBrains IDE just to gain a cheap popularity. JetBrains distanced themselves from supporting flatpak from the very beginning. Yet, they are blamed why it doesn't work properly under flatpak. It's been suggested that JetBrains IDEs are bugged and maybe even unmaintained by upstream. Yep, Flathub members always blame "lazy" developers for all issues, doing virtually nothing to fix the problem on their side. They also started a campaign against Snap on Reddit. Unfortunately, accounts with their posts have already been deleted, but you can still find some references. Anyway, they stated that Canonical wants to take control of the Linux software, the whole Snapcraft is corporate-driven and it is against the Linux community. Is that so? Well, not really. When it comes to Snapcraft, anyone can put their package there, while it's not that simple on Flathub. On Snapcraft, you have much more freedom. For example, you can provide some Windows software wrapped in WINE, when it is explicitly forbidden on Flatbub (BTW, on January 1, 2019 they stated that they are open to share their build infrastructure with others, and just less than two weeks later they started yelling that using it for non-Flathub packages is "abusing the build infrastructure"). On Snapcraft, you can even submit your own variant of the program if you think it's better than the official one (see: qalculate and qalculate-jz). On Flathub, there is a problem with submitting the Qt-based application if the Gtk-based variant is already there. When it comes to permissions, you can generally do more on Snapcraft, where permissions are granted according to strict rules, not discretionary as it is on Flathub. The Flathub runtime, for some reasons named Freedesktop (they claims it is "distributions agnostic, desktop environment agnostic, and package format agnostic", but it isn't really true - it may be adopted to other package formats, but right now it isn't truly agnostic), has been approved on Snapcraft as a community runtime, although in reality no one except GNOME is interested in it, and GNOME members generally don't publish their applications to Snapcraft. Canonical also gave the green light for Fedora runtime. On the other hand, Flathub has rejected Fedora runtime. Why? Because it "stinks"... What else? Flathub members stated that Snap is strongly tied to Ubuntu and there is no way it could properly support other distros anytime soon. How is it actually? Snap officially supports over 20 distributions. It is pre-installed on Manjaro, Ubuntu, Solus and Zorin OS. It supports Arch, Debian, openSUSE and others very well. Only in the Red Hat world (EL and Fedora) it have some serious issues, partially because snapd packages are intentionally broken there (but it isn't the only reason). Flathub also claims that it supports over 20 distros. However, support for LTS distros is often broken. From time to time, even normal distributions ( e.g. openSUSE Leap, Mageia, Mint, elementary OS, Endless OS, etc.) are affected by some issues. It happens that problems affect everything that isn't bleeding-edge, including openSUSE Tumbleweed and Fedora Rawhide. What's worse, Flathub constantly pushes developers to make changes that will break packages on older (but still officially supported by Flathub!) distributions, e.g. by removing direct dconf access.

When I am maintaining packages, I always try to not only build the software and its deps correctly, but as far as possible I try to fix the annoying bugs and improve its quality. For example, I've provided some patches and other fixes for Aegisub, gImageReader, NaSC, RawTherapee, wxMaxima, Widelands, XnRetro and dozens of other programs. I put even more efforts in polishing Notepadqq and OCRFeeder. Vendors usually appreciate my work, like it was e.g. in the case of Widelands ("Thanks to the work of scx we can now provide development builds for all distributions.") or OCRFeeder ("I gotta give my special thanks to the community member scx who not only fixed a few important issues and added a couple of quick improvements, but also was patient enough to wait for my delayed reviews last year, and even created the flatpak for OCRFeeder."). Back in time, I provided the Steam package for EL6, which gained some popularity. Then I provided some stuff to EPEL, ELRepo and Nux Dextop. My packages have also been somehow reused in other repos, such as RPM Sphere. I was also spotted at COPR, where I provided literally hundreds of packages. I often got nice e-mails from people who thanked me for maintaining packages. For all these years, only the members of Flathub sabotaged my work and tried to discredit my person: "To keep it short, submitter repeatedly ignores reviews, changes request and instead of acknowledging their poor behavior and doing something about it, keep saying it's a personal thing. While as admins we are not affecting day-to-day maintenance too much, it's important that everyone is cooperative instead of turning Flathub into some kind of playground." & "And here we go again, playing victim…" Eventually, they admitted that they were doing it for non-technical reasons: "In the end his manifests are often acceptable but they are a difficult person to work with and that is not ideal for the community." And I am "a difficult person to work with" just because I can't handle constant trolling and software fascism, i.e. discriminating one software and privileging another.

It's up to you if you want to care about the flatpak package, but I'm done here.

scx commented 3 years ago

@Benitoite

Filesystem Access should be set to host to access /mnt

According to Flathub members, it should be limited even more (to --filesystem=xdg-pictures). Technically, I could add the --filesystem=host permissions, but I won't do it, because it would be revoked very soon. You can try it on your own responsibility, but I don't know if you will experience any repercussions for this (according to Flathub maintainers, you can lost "push access to your repositories" on Flathub). If you're lucky, no one will notice. This was the case with RedNotebook. I was forbidden to give the removable devices access on Flathub, and then two years later, the author gave them by himself. BTW, there should be no need to ask me about this. According to the Flathub members, it is the software vendors that should deliver their applications to the Flathub store: "Flathub is primarily intended as a service that is used by app developers to distribute their apps". You should have full access to the RawTherapee repository on Flathub. Why don't you have? Because you've criticized flatpak and promoted a technology that competes against GNOME's flatpak in the past. This is how Flathub works. Not everyone is welcomed.

As an user, you can manually override package permissions with the flatpak override command. When it comes to the GUI, there is a problem. While snap can provide Snap Store, flatpak can't provide GNOME Software. GNOME Software was supposed to be just a front-end for PackageKit. However, they screwed up. PackageKit is dead, officially. Still, they blame Canonical for that Snap Store can only handle snaps. Since it uses strict confinement, it can't support anything else (even native package, like RPMs or DEBs, so it's not like it discriminates only flatpaks), because there is no such API in the Linux world. If you want to blame someone for this, you should blame Richard Hughes, who is a Flathub/GNOME member, sponsored by Red Hat. He was responsible for PackageKit. Anyway, if you're lucky enough, GNOME Software will let you manage some flatpak permissions, at least in a limited way. On my systems (RHEL 7, CentOS 7), it just crashed (Segmentation fault (core dumped)) and GNOME Control Center is completely broken under MATE. If I good remember, in the past it was possible to grant and remove Home Access, which by the way actually could break some applications, because not every software uses XDG user directories, and flatpak cannot really blacklist the ~/.* files and directories. BTW, contrary to what Flathub members say, XDG_CONFIG_HOME is not "the new Linux standard". For example, snap uses SNAP_USER_DATA instead. Just because GNOME devs have integrated support for XDG user directories into GLib, doesn't make this "the new Linux standard".

scx commented 3 years ago

@Benitoite

paperdigits has some RT flatpak experience to bear.

I don't want to be rude, but last time he wasn't even able to build gtkmm, so he asked for help here. You should know that when my app submission to Flathub was accepted, I didn't get repo access right away, allegedly by an "oversight" (previously my submission was blocked for many months without any reason). Anyway, there was a need to apply my patches, so he tried to do this, but he failed, so I had to fix it by myself later. Then he removed the dconf access, which resulted in the lack of support for HiDPI in many distributions (at that time: at least RHEL 7, RHEL 8, CentOS 7, CentOS 8, openSUSE Leap 15.1, Mageia 6.1, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Mint 18, Mint 19, elementary OS 5 - and even now EL7 is still affected, although it is still officially supported by flatpak). I told him not to do it several times, but he ignored it. Since then, he hasn't had any interest in this flatpak package at all. In the end, in my opinion he has very limited knowledge of flatpak and RawTherapee itself. I am not saying that you shouldn't use his help, but you should keep a careful eye on him and very carefully watch what he is trying to do.

scx commented 3 years ago

TL;DR

According to Flathub members, everything is fine. It's not a bug, it's a feature. You should even limit the filesystem access (to --filesystem=xdg-pictures) instead of increasing it (to --filesystem=host). If you do the second one, you may be banned on Flathub. As a solution, you should use flatpak override instead, because it is "easy for users". I don't agree with this, but there is nothing I can do about it. This are the Flathub rules.

Thanatomanic commented 3 years ago

@scx What is going on here? Why is there a 7500+ word post (and then some) in response to a seemingly reasonable request? From a quick scan you seem deeply frustrated with the Flathub community. I am not sure if you're taking it out on the RawTherapee project as well, or are just generally venting.

In any case, is there something we can do to help?

scx commented 3 years ago

@Thanatomanic

As I said before, I have always tried to give the highest possible permissions to satisfy all users (and since the flatpak sandbox is mostly a lie, I see no reason to apply strong restrictions). Unfortunately, on Flathub it is impossible, not because of some real guidelines, but because they discriminate one software and favor another, as I just proved above. I would like to grant the --filesystem=host permissions to RawTherapee on Flathub, but as you can see, it's not that easy. Darktable is allowed to use such permissions, and RawTherapee it not, just because Flathub/GNOME members said so. I don't know if anything can be done about it. I could describe this topic in more detail (there were even more examples of discrimination), and try to get the media interested in it (e.g. Phoronix), but to be honest, I don't know if it will change anything. And it already took me a few days to write all of it (I started on July 29...). I could suggest providing a snap package, but RT is one of those apps that will be useless without classic confinement, and there are some restrictions about using it. Anyway, manual approval is required. I'm not sure if I have enough patience to deal with it, but at least in theory, it looks like it's worth the time.

paperdigits commented 3 years ago

@scx

I don't want to be rude,

But you do want to be rude, as you've done this multiple times, and it is indeed extremely rude to try and shame people for asking questions to try and improve their knowledge.

It is pretty sad that even years later you haven't figured out that the reason you get such flimsy answers from the flatpak community at large is because your interpersonal skills are so bad that nobody even wants to take the time to engage with you. You're so abrasive, rude, and so unkind that nobody even wants to speak with you long enough to give you a technical explanation, so they push you off with non-technical things.

Since then, he hasn't had any interest in this flatpak package at all.

You are completely correct that I have absolutely no interest specifically because you're involved with it and I don't wish to spend my free time dealing with inhospitable bullshit.

I could describe this topic in more detail (there were even more examples of discrimination), and try to get the media interested in it (e.g. Phoronix), but to be honest, I don't know if it will change anything. And it already took me a few days to write all of it (I started on July 29...).

You should absolutely do this, perhaps the results of such things will shock you into some self reflection.

Thanatomanic commented 3 years ago

@paperdigits @scx This is not the right place to discuss such a personal matter. I do not oversee the scope of this matter yet, but if needs be we can discuss this in PMs on Pixls.us. I am willing to medaite and work towards understanding the problem and solution if it benefits RawTherapee's distribution.