Well, in this case it seems like there already is an official Flatpak, but Fedora is overriding it with their own, which is of lower quality. The problem was already solved, unless Fedora is claiming that their Flatpak is better in some specific way.
From what I can tell reading the pagure.io thread (https://pagure.io/fedora-workstation/issue/463#comment-95541...) the claim from Fedora is that is that OBS is using an EOL qt. It's hard to follow exactly what the issues are with the Fedora flatpak but I can only assume they forcefully updated qt and that's what caused the issues (just a guess from the context).
There's a lot of interesting debate in the linked thread about Fedora giving leeway to "verified" flatpaks, or what they're calling "probably safe" apps that do not request too many permissions, so even if there are vulnerabilities in the source then due to the nature of flatpaks, they won't be able to cause much harm.
> the claim from Fedora is that is that OBS is using an EOL qt.
what's amazing with this is that if for instance OBS had written their own toolkit from scratch just for the app, which by a stroke of luck ended up being exactly the same code than the Qt version they're using and which solves the use case they have - maybe it would be OBSObject or OBSString instead of QObject / QString, then this entire issue would not exist as no one would think of saying that their implementation is "EOL" since it's part of their app even if the actual GUI implementation files may not have been touched for 5 years.
First, the risk is higher. When a vulnerability has a public patch, it means the nature of the vulnerability is also public. Sometimes there is even public exploit code. While attackers sometimes find their own vulnerabilities (zero-days), it makes their job a lot easier if they can just use an already-known vulnerability.
Second, if the code was part of the OBS project, then anyone reporting security bugs in the code would report them to OBS. OBS would then be able to quickly release a security update if they decided the issue warranted it. But since Qt is external, security bugs will be reported to Qt, and it’s unlikely anyone from OBS will hear about these reports. So there is no process for the project to respond with quick fixes even for severe issues. That is, unless they have someone watching the list of CVEs - but that seems unlikely.
Third, if the OBS project had written the code, then it would be reasonably likely that someone on the project knew the code well enough to properly maintain it over time. This isn’t always true. Sometimes projects are stuck with huge piles of code that nobody wants to touch, whose author has left the project, or perhaps just forgotten how it works. But it’s true more often than not. In contrast, most projects don’t engage with their dependencies’ source code to such an extent, especially not for something as huge as Qt.
Fourth, on a related note, vulnerabilities often come from newly written code. Probably the biggest reason for this is that security bugs often double as regular bugs, causing crashes or other issues for normal users. This isn’t true for all security bugs: a decent chunk of them have very specific triggering conditions that are essentially impossible to produce by accident. But it’s true for many. If OBS really had left the code untouched for 5 years, then that would probably be because the code worked pretty well. Maybe it’s legacy, maybe it’s not well-maintained, but if the issues it’s causing were really bad, someone would have gone in and fixed it. That in turn reduces the chance of security bugs somewhat. In reality, OBS actually is regularly updating Qt and thus pulling in new code that may not be well tested. (But not regularly enough to be up-to-date with security fixes.)
Fifth… at the risk of sounding entitled, it’s not just about the risk but also about the potential upside. If there are security bugs in OBS-specific code, that’s bad, but all the ways to improve the situation involve doing OBS-specific hard work. With Qt, there is already someone else doing the job of finding and fixing security vulnerabilities; OBS “only” has to pull in the fixes. In practice, of course, it’s more complicated than that. But if we have a system where it’s Hard to pull in security fixes that someone else has found, well, maybe that’s not OBS’s fault, but that does mean it’s a bad system. We should aspire to do better.
> First, the risk is higher. When a vulnerability has a public patch, it means the nature of the vulnerability is also public. Sometimes there is even public exploit code. While attackers sometimes find their own vulnerabilities (zero-days), it makes their job a lot easier if they can just use an already-known vulnerability.
but.. Qt is only used for the GUI in OBS. It's not doing anything network-related or processing any data stream coming from there, why would any security issue in Qt matter ? Only thing I can think of is a crafted system font causing an issue but if you have a crafted font running on your linux system you are already compromised way beyond repair
Who cares what they claim? Flatpak was invented specifically to route around finger wagging distro maintainers.
Fedora has OBS in their native repos. They can go apply all their opinions to that copy. And if they're as right as they think they are, I'm sure upstream will be happy to take their patches for inclusion in the next flathub release.
Is that all there is to it? That doesn't mesh with the separate claim that Fedora's RPM package of OBS is acceptable to upstream - surely that uses the same latest Qt that Fedora offers? Fedora 41 already ships the very latest Qt 6.8.2 release.
Simple answer: Whoever the upstream decides should do it. For my code I'm very happy to have distributions shipping packages because it means the code is available more easily for users and with less work from me -- but if a distro was shipping a broken package I would absolutely say "please stop doing that".
But not the right to distribute with an intact trademark. No open source license provides that right.
If the Blender Foundation one day decided that only the Windows and Mac App Stores can distribute Blender, yes, Linux distributions would be forced to use a different name.
1. Just read the license. Never is a trademark granted. Source code can and is granted completely independently of trademarks (otherwise, as one example, how does Apple license iOS SDKs without permission to use the name “Apple”? It’s just a more stringent license than a FOSS one.)
2. It’s already happened, Debian wanted to change Firefox, Mozilla said no, lo and behold we had “Iceweasel” for a decade.
I think you're misunderstanding trademarks. As an example: if I buy a 12 pack of Coke, I can set up a table and sell them one can at a time. Trademarks require that I don't present that I'm sponsored by Coke, or label my non-Coke as Coke, or a variety of other things that would confuse consumers. That's the entire premise of trademarks: avoiding consumer confusion.
To your example: Debian had to rename their package because they were making modifications to the code of Firefox, so it wasn't Firefox anymore.
OBS could try to make the claim that how Fedora is packaging their code modifies the code, but that's way more tenuous given that building the product with different versions of its dependencies isn't really changing the code.
I think it's easy enough, ignoring the technical details of why, to just look at the results: the version of the app in fedora's repos is inferior to that on flathub produced by the developers. Exactly why this is the case is irrelevant, what matters is that users are getting confused, thinking they are getting an official version of the product, and that this is causing damage to the developers who own the trademark (extra effort in dealing with bug reports, loss of reputation).
Considering that trademarks have a long case law with being used to force redistributors offline (i.e. to force my app to not be available on Download.com); I think it is fair to say that it is well established that a trademark gives the owner total distribution control except where the first-sale doctrine intervenes (resale of a product acquired through a legal seller). That doctrine only exists for physical products though, and specifically for items that can be “bought.”
In the real world, Coca-Cola would "force a redistributor offline" by not selling them products, and setting up agreements with their distributors to limit who they can sell to. That's not trademark, and it doesn't transfer to free software.
If distro maintainers are going to futz with packages, for good reasons or bad, then they need to bear the corresponding support burden themselves and ensure it does not fall on the upstream maintainers. This is not really any different from the Debian OpenSSL fiasco, or the Debian cdrecord fiasco, or the Debian xscreensaver fiasco, or...
says it was hardly a Debian thing. More to the point, I'd argue that there is a meaningful difference between "we're going to patch this" and "we aren't confident that we can ship this at all".
Whoever's going to do the best job. Sometimes that's the distro packager, sometimes it's the upstream app developer. With complex applications with lots of dependencies and a large surface area for breakage between versions of dependencies, it's far more likely that the upstream developer will be in a position to do a good job than a distro packager who's responsible for 100 other packages, and maybe never actually uses the application, especially when they're constrained by distro policy on vendored dependencies or multiple library versions (which, like, I get the reason for, it sucks for a security fix to need applying in many different places, but it's a policy that will inevitably create bugs).
This is something which grates when reading the defense of Fedora's flatpak repo in the thread linked elsewhere in the comments, claiming that Fedora is going to package with much higher quality and more testing. I can believe that relative to some rando 3rd party on the internet, maybe (at least that rando probably has packaged it because they would like to use it personally), but relative to the developers themselves? I think that's pretty unlikely.
I think the main issue in this case is that the maintainers provide an official flathub entry themselves. People using the fedora flatpak are not aware that they are using an unofficial (and incomplete) package, and then go to upstream with their issues.
The whole point of flatpak is so that the upstream maintainer can release one well tested binary and it works on all distros...
As a long time Linux user and someone who tried to get in some software into Few Linux Distro Repositories, it's high time we start recommending the above model.
Not my words, but at this point I'll even take just a zip file with apps that always just works over having to deal with all the headaches from distro package managers for user level software.
This problem was already solved. OBS ships a package on Flathub which can be installed on any distro. There is no reason for Fedora to package their own broken version.
- upstream maintainer: too much work. each distro requires certain best practices/convention.
- distro: may not meet certain standard set by upstream maintainer.