The OBS Project is threatening Fedora Linux with legal action
gitlab.com
gitlab.com
For those who don't have that in their context - jwz got very upset at people reporting bugs against xscreensaver that had been fixed for a long time in upstream but e.g. Debian doesn't just ship upstream updates every 30 minutes. He requested Debian stop shipping it (or update it? I didn't go reread the entire chain before replying), Debian declined.
He then put in a piece of code that popped up a notification if the system time was sufficiently far past the hardcoded value, informing people they should upgrade, and Debian debated patching his message out.
[1] - jwz dot org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
(Link turned into not a link because I had forgotten how jwz feels about HN referrers.)
When I said "article," I guess I meant that I don't want to watch a youtube video detailing the drama or whatever, I was hoping to just read about it. Either way, thanks for the link and the explanation further down the thread.
Considering that I've spent many a night at Bootie SF (back when it was at DNA Lounge) on too many drugs or alcohol to respond to on-call issues, it's entirely possible that he had more power over tech than it had over his life.
Like many people in San Francisco, he is an intelligent guy with great will to power and eccentric views.
Many of whom share his same opinion on VCs and late stage capitalism.
I don't hate him and didn't write anything of the sort. I've never met him. He might as well be the tooth fairy or the Easter bunny as fas as I'm concerned.
> the fact remains that probably 95% of ycombinator funded startups couldn't exist without making extensive use of the gpl, bsd, Apache and similar licensed software produced by a lot of open source curmudgeons and greybeards. Many of whom share his same opinion on VCs and late stage capitalism.
I've been using FOSS for personal use since I was a child. I'm a literal card-carrying supporter of the FSF. I'm more passionate about it than I am shitting on random people on the internet. If he has a problem with VCs then he can spam them with pictures of genitalia and ad-hominem attacks, not me, who's just some random dude who _isn't_ worth millions of dollars from a software business exit (along with thousands of others on this site).
Not that I would seek to deny your valid annoyance and offense. It's a non-consensual scrotum in a teacup. I personally would have gone a different direction, I get why that would raise someone's hackles.
wait, this would be a bad thing?
Highly recommend installing https://addons.mozilla.org/en-US/firefox/addon/smart-referer
<https://jwz.org/blog/2016/04/i-would-like-debian-to-stop-shi...>
- https://bugs.gentoo.org/101619
- https://bugs.gentoo.org/124595
And Quod Libet vs. Debian (2007):
There's plenty of other examples, of course - one that springs to mind was when Ubuntu shipped a patch of their own design in OpenZFS that caused data loss, and it got reported to upstream.
And credit to Fedora, it looks like they're working quickly to fix the problem now. It's pretty obvious it wasn't malice that led them to not respond quickly.
So stupidity then.
Seems legit.
I’m a Fedora packager (not for this package). Like many others I have an unrelated day job.
If there’s an upstream complaint I might get to it this weekend, maybe next. If I’m busy for a few weeks that doesn’t make me stupid.
Have had my share of “discussions” with upstream who want the latest version packaged when this might not be completely in line with our guidelines. Not an uncommon issue.
But equally, I don’t think it’s fair that packagers want to have it both ways. Packagers want to make subtle, possibly breaking changes to software they didn’t author. The end users feel the pain and complain to the author. The author has no control over the situation, and they’re feeling the pain during the working week.
So the packager has been instrumental in creating the problem with the patch, and when requested to do something about it, turns around and says “buddy I do this for free, I’ll get to it over the weekend, maybe.” Sure, but the author is feeling the pain right now.
Again, it’s nice that you’re volunteering your time for others. But it would be good if you acknowledged that the costs of packaging aren’t borne entirely by packagers. Authors bear part of the cost when they get blamed for broken software.
I suppose my advice to upstream would be to direct the end user to the Fedora bug tracker, where the bug can land in my queue. Or advise the user to install from a different source.
The upstream that I’ve dealt with have been kind enough to lodge a bug themselves on the package I look after, which is also an option, and much appreciated.
How is upstream supposed to make this happen when distro maintainers not only don't mark the package as modified by them, but also silently change the flatpak configuration so that installing packages from flatpak in the way that would normally install a clean upstream build doesn't do so?
Less of a poor faith comment, more like a badly landed gag. In my head, everybody would have known I was riffing off:
"Never attribute to malice that which is adequately explained by stupidity." -- https://en.wikipedia.org/wiki/Hanlon%27s_razor
I vaguely remember this happening but I’d need to check.
This grossly understates the problem.
The debian xscreensaver package was years old, and contained bugs related to screen locking which were an actual security issue.
Your comment is in very poor taste.
In contrast, Red Hat Enterprise Linux, a distro funded by IBM and countless faceless backers, has recently stopped patching many vulnerabilities, recommending to their users to rely on mitigations instead, despite the availability of upstream patches.
Furthermore, the recent vulnerability threatscape is inundated with CVE hunters who are desperate to call the most minor degradation of service a vulnerability. For a community project (and apparently an enterprise-serving megacorporation), this causes patching fatigue.
I'm not really sure why everyone is focusing on that phrase, though. I think it's pretty clear if you read any of the source material, as said, that that is not an accurate representation of what was going on, and I would have also expected "every 30 minutes" to be a pretty clearly hyperbolic expectation for anyone to process updates after.
Is everyone focusing on the phrase? I thought I asked about it, and that's all that's happened.
> I would have also expected "every 30 minutes" to be a pretty clearly hyperbolic expectation for anyone to process updates after
I couldn't imagine a benign use of hyperbole in timeliness when some expectations of timeliness are silly, and some are sensible. I thought I'd ask, in case there was a good faith reason for it, rather than just assume you're trying to use insinuation to change people's minds.
So they grossly understate the problem, make it seem like it’s the person authoring the software at fault or the one who’s being unreasonable.
They’re quick to tell you how great the maintainers are, how much effort they put in for free but they don’t share that same love for the author of the package. You know, the person who actually wrote the software. They don’t acknowledge that without the author they’d have no software to begin with, and that providing support to older versions of software is a cost to the author. Not just older, but possibly broken in subtle ways because of the patches applied on top. The author still gets all the blame and all the support requests for changes they didn’t make.
To be clear, there’s nothing wrong with wanting to run old, stable software. No one questions that their distro is “the most stable”. That they cannot or will not see the costs of doing so on the author is a shortcoming, but there’s no solving that.
> To be clear, there’s nothing wrong with wanting to run old, stable software.
I personally run on latest, apply all updates zealously within a week or two.
They have different goals/purposes, often, and they frequently don't line up with my own.
Maintainers are exhausting in their own right, they do a ton of work and so they think their decisions are more important because of the work they do, user be damned...
Authors usually only care about their version of the software.
I think, a better medium, would be if a third party is packaging an application, perhaps they should always explicitly state they are the ones packaging it. Then there is less confusion.
Or, you know, let the author keep control of that...
That's rich, coming from a project very closely tied to Gtk, which has a history of massive breaking changes, and outright removing functionality, leading to many projects continuing to use older versions of gtk for a very long time.
I believe they mainly remove functionality between major releases of GTK, not within a release. Can you cite an example where they have done this between gtk minor releases ? Aka gtk 3.1 -> 3.2 ?
Fedora KDE is literally release blocking and has been approved for promotion to be on the same level as Fedora Workstation.
Red Hat isn't as involved with Qt, which is mainly maintained by yhe Qt group company.
RedHat employees make the majority of commits to Gtk and I think are some of the maintainers/managers?
Why do they still mingle with sw distributions? Wasn't the sandboxed blob trend born also to try blackbox strategies and have parallel versions without dealing with too much hell? Was that laziness/economical advantage (EOL'd library, no business in porting fixes, upgrade to the latest and greatest) or something else?
For this reason I don't understand why did they changed the library in there (that build of OBS wasn't broken because of system-wide libs, it was because allegedly they changed the lib in the flatpak), whatever the security hole couldn't they block it "from the outside"?
Fedora has its own Flatpak repo as the default instead of Flathub (which has the official OBS package from the upstream developers).
The idea behind it is really for corporate uses of Fedora/GNOME. Sysadmins, through Fedora Flatpack, can re-package certain software from Flathub in accordance with their draconian corporate policies.
As a person that has had to endure stupid corporate policies and since Fedora is _mostly_ used in corporate workstation. I can understand this.
What I don't understand why it's the _default_ to prefer Fedora Flatpack software over Flathub. For people that are just getting into linux, I can see why that's painful and the UX to be terrible.
"I installed Z software. It installed some junk re-package. I only realized it installed junk re-package after a week of investigation. Installing it from different source and now it works. Thanks, Fedora! I wasted a week of my time!"
Also, distributions can also provide their flatpak repos (or even another third party) and vet the packages with their own set of rules (such as "no packages with full filesystem access").
That's the main reason I never took Flatpak seriously.
It's also very worth noting that `Fedora's Flatpaks` are sourced separate from the "Main" `Flathub` service which most people expect flatpaks are generally being sourced from which has many "official" flatpak releases of software directly from projects leading to extra confusion.
Flathub itself is fairly auditable (but not trivially so) and built through their CI, but I still agree that the unofficial packages are often of questionable security/quality.
That said, Many of the "native" (e.g. not Flatpak) distro packages are using far from supported/official builds with often missing/broken features and it's an unreasonable support burden when nearly all of issues related to distro packaging end up on the upstream issue trackers/support channels.
It's especially troublesome when the upstream has official builds available and it's unclear to the user reporting issues that they are not actually using official builds.
When I open Software I always think it's going to be a clean GTK interface for dnf. But it appears to just do its own thing, and I've learned not to trust the app listings in there.
I still uninstall it and use apt instead (and "downgrade" packages that are wrappers around snaps, and block snapd from being able to install...).
...why?
https://pagure.io/fedora-workstation/issue/463#comment-95541...
> keeping up with runtime updates is one of the most basic expectations of a maintainer, and I suspect it's a sign there may be other problems as well.
> I won't mince words: allowing the runtime to go EOL is unacceptable and indicates terrible maintainership.
I don't use Fedora but I do use OBS… on Mac, because OBS is hands-down the most popular application for streaming on any platform. It's crazy that OBS works great on Mac, works great on Windows, works great on Linux if using the OBS Flatpak, and when the Fedora-packaged-flatpak breaks and this Fedora guy starts saying that this is indicative that "there may be other problems".
If OBS isn't good enough for Fedora to ship a working version, then show me the streaming software that is.
> Flathub maintainers are sometimes just bad at maintaining their packages, and, well...
"If OBS isn't good enough for Fedora" - fanboyism is never good. If OBS has issues in development then what? What would you do if it stops updating Qt permanently? Think not let emotions act.
"works great" - doesn't mean it is secure.
You can write application that works great and is swiss cheese from security standpoint. You can write secure application that works like nightmare.
"inappropriate" - why? If it is statement of fact then it can not be inappropriate.
Also mind you OBS blocked the issue about fact that they use EOL qt on github - this does not look to me as good project.
"the Fedora-packaged-flatpak breaks" - is it broken? Because no one even speaks about real state of package! Or by "broken" you mean - does not have functionality I want! Or it uses Qt version which breaks the application!
Because In first case that not breakage - that's loss of functionality and if motivated by legal reasons - I can understand (not approve since US software patents are from my perspective idiocy), if motivated by security I wholeheartedly approve - because you are shooting messenger(fedora) of bad news(OBS bad practices) here.
In second - Qt is broken so send regards to them and their policy: Update it so often to make GPL/LGPL version as miserable as possible. Which they then use to sell companies the LTS versions under proprietary license.
I agree with breaking (it is good feedback about software state) to modernize dependencies - but then again I'm using Arch so…
AI generated SaaS app launching in Q2 and we’ll IPO later this year.
Crazy how much drama happens in open projects like openAI.
It feels like they'd have a hard time making that case, since package repositories are pretty clearly not representing themselves as the owners of, or sponsored by, the software they package.
Yup. The issue isn't the code but misrepresentation of the origin. It's like back in the day when Debian "forked" Firefox for reasons...
Edit - worded it poorly - never meant to imply Debian did anything wrong, only that they changed the branding to respect Firefox's trademark and avoid the situation that OBS is threatening Fedora with.
Debian didn't actually change the code, but they consider the right to change the code important, and don't accept Debian-specific exceptions.
The main issue that I see, is that OBS doesn't want to be held responsible for the Fedora version, which is different from the "officially-supported" OBS version. They didn't modify anything other than the build, to exclude certain dependencies.
But modifying the build, is modifying the code. They are allowed to do that, but they probably aren't allowed to slap the OBS name on the result.
Is it? Across Ubuntu, RHEL, and Archlinux, basically every package is being built against different versions of its underlying dependencies, and is being patched as needed to work with those distros. Trademarks weaken with lax enforcement, so you'd think if that interpretation held it would be amazingly dangerous for any trademark holder whose software was being packaged for Linux distros.
I suppose the closest analogy I can imagine from non-malicious(arguably) history would be software hosting sites that would repackage installers with their own adware or toolbar or whatever "value add".
By using the brand on something else, the reputation can be damaged
https://bazaar.launchpad.net/~mozillateam/firefox/firefox.ja... is the config for what becomes Ubuntu's firefox package
https://gitlab.archlinux.org/archlinux/packaging/packages/fi... is the equivalent for Arch
Both apply different configurations, use different versions of dependencies, and in Arch's case applies a patch to the upstream code.
Which of them isn't Firefox?
They had distribution networks, authorized to carry their brand.
But there were also “gray market” distributors, that would do things like resell foreign market gear, or devices that were separated from sales promotion bundles.
These were our brand, but the company would not support them. No hardware fixes (unless paid), no firmware upgrades, and no marketing support.
Often, the savings were minimal. It was expensive gear; even at a discount.
To be clear here: They do modify it further than that by applying a number of patches.
For example, they replace libx264 with OpenH264 which also requires some changes to the UI code since it is (unfortunately) hardcoded to expect x264 to exist. While there have been efforts to upstream those changes, they have not yet been merged.
It seems (to me) to make sense, for OBS to want their name off of it.
> This is a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project
Honestly it sounds very reasonable, if you want to fork it's fine, but don't have people report bugs upstream if you're introducing them.
What should they call the (demanded) fork?
Also, Flatpaks have different file paths (like NixOS, which has updated packages according to e.g repology), and so selinux fails with many or most flatpaks.
Isn't the argument that by mangling the software, they've created a version that is no longer the original software, and the the trademark owner want them to stop using the trademark to describe this new version? I think OBS would be happy enough if Fedora simply decided to release their own "FBS" package instead that was the same, other than describing it as "OBS", which the trademark owners have specifically said it's not.
From the first line of the IceWeasel Wikipedia entry:
> At issue were modifications not approved by the Mozilla Foundation, when the name for the software remained the same.
Governments dislike insecure.
Compare this to Windows, where you often have to search the Internet, download some sketchy .exe or .msi and don't know if you'll get the software, a virus, or both.
It got so bad that it was common to have "cleaners", extra tools that you downloaded (often from similarly sketchy sources) that tried to delete the sketchy parts of other programs, the remnants of incomplete deinstallations etc.
I still remember when putty download was http-only, no HTTPS, and that was just a few years ago...
HTTP downloads are still fine in 2025 though, putty releases all come with signatures that can be used to check if anything was tampered with.
This is how lots of Linux package managers can still use HTTP for downloading from mirrors without worrying about malicious package modifications.
1) People don't check, and 2) the root of trust for those signatures is almost always the same HTTP source as the download!
In contrast, package managers do check, and they have a root of trust at least from install time.
It just works if the software you require is not only provided by your speciic distribution but also you require the specific version of the software that is provided by your specific distribution. Good luck if it not the case.
For windows or mac, 1 or 2 files each cover all systems from the last 10 years or more.
It's not by masochism that people regularly try to find solutions for linux by reinventing the wheel like appimages, snaps or flatpaks.
> , download some sketchy .exe or .msi and don't know if you'll get the software, a virus, or both.
You compare hunting for pirated software to installing open source software. You don't have more risk downloading an installer directly from the dev than from your distribution. And probably less once you go outside the main distrib.
> It got so bad that it was common to have "cleaners"
Yes windows has issues of letting remains of software that you desinstall(don't know for mac). But linux has issues too with remains, if only in your local directory.
I'm not saying that the other systems are perfects but the developers don't need to produce binaries/installer for 200 distribution times 10 version for each distribution
Utter nonsense. What about code signing? A 10 year old installer won't be signed, and Windows/mac will scream at you about malware and you might have to jump through a bunch of hoops to get it actually installed.
> You compare hunting for pirated software to installing open source software
Pirated? How do you download MS Office? Adobe Acrobat? VLC? For all of those, on Windows and on Mac, you have to search the net for an installer. And pray that your vision is good enough to detect phishing/scam websites. (And sometimes it isn't obvious, VLC is downloaded from videolan.org).
It also just works if you install a Flatpak, which on distros like Fedora, you will be able to do by default through the software store app.
https://src.fedoraproject.org/flatpaks/obs-studio/history/co...
which reads:
``` end-of-life: The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build. ```
It does not take away that this feels pretty unnecessarily hostile, as Neal already informed him to work with the packager to resolve this: https://pagure.io/releng/issue/12586. It is not clear if the reporter actually ever did.
In another comment someone says that most of the extra packages are maintained by a single person (more than 700), there's no way a single person can validate and test all these packages (or even use them).
They should never package what rpmfusion offers, or distribute a new flatpak when something is already available. That worked when flathub didn't exist or was mostly empty, but that time is gone now.
Note: I want to understand what led to the comment of the C&D-like legal threat.
Original vision https://pagure.io/fedora-workstation/issue/463#comment-95406...
Person with more than 700 packages https://pagure.io/fedora-workstation/issue/463#comment-95541...
As for the C&D, the github has some issues with Fedora distros and labeled as "Dependency issues" and there's no indication if the user is using the fedora flatpak or the flathub one, so if I had to guess I would guess that they aren't that happy with:
1. Being asked to fix bugs introduced by downstream.
2. Having their brand damaged because it isn't clear that the fedora
flatpak is a way more limited version than the verified one.
3. Having their issues with their complaints minimized and ignored by
the people responsible for the fedora flatpak system.yes, it recently got unfortunately heated with the whole "whose idea about what to do with Qt is better" argument, but the whole way through that ticket - which was filed 23 days ago, and has had active discussion going that whole time, including being the main topic at multiple workstation WG meetings - it's been pretty clear that the outcome is likely to involve Fedora flatpaks being demoted. The very first post is a proposal - by a key member of the workstation WG - to move flathub ahead of Fedora flatpaks in the precedence order. Consistently through the discussion, catanzaro and other workstation WG members have been supporting that idea, with a lot of discussion and argument about the details, as you always get in F/OSS projects. we do all the sausage factory stuff in the open, that's the point.
The obs-studio Fedora flatpak exists because the maintainer (yselkowitz) decided to make one. Ditto the few hundred others that exist - https://src.fedoraproject.org/group/flatpak-sig . Some of those are dupes of flathub, some aren't. Of the ones that are dupes, in some cases the flathub build is 'official', in other cases it isn't.
and yeah, yselkowitz created a lot of them, most of which are very simple - it's not really a lot of work to create a flatpak when there's an existing package, the definitions for most of them look like https://src.fedoraproject.org/flatpaks/bless/blob/stable/f/c... . Kinda the point of Fedora flatpaks is that you get a lot of the work done 'for free' in the package build.
I don't know why he decided to create all of those, maybe the idea was to try and create a critical mass of stuff so it would be kinda viable to get all your software from Fedora flatpak repos the way you can get all your software from Fedora RPM repos, if you want to.
Considering that one person that says that he worked at the beginning of the project writes that the original idea wasn't to compete with flathub and given the current state of affairs I would argue that the project today doesn't have the original vision anymore.
As for creating a ton of projects, today with LLMs I'm pretty sure that I can write code that scrapes github repos for installation instructions and use it to create thousands of packages for everything that can run in Linux, doesn't mean that I should because there would be no quality control at all.
It is a noble idea to create packages to help create critical mass, but even with simple packages, seven hundred are more than anyone can use specially when we're talking about software that most likely have a GUI, and if you never really use most of the packages that you create you are bound to create these issues with QA.
All of that could be avoided (or minimized) if the fedora project created two flatpak repos, one for core software and one for contrib software, but that probably would be clear competition to flathub and probably be mostly ignored.
Just providing context here, this is what one of the OBS maintainers said in Brodie Robertson's video [1] about this issue:
> Hi, Joel from OBS here, thanks for the coverage! I can confirm that we absolutely did not want to have to resort to this, but did not feel that they were taking the concerns seriously, and when they resorted to calling us "terrible maintainers" we felt they made their position clear. I'd like to also let folks know that Neal Gompa (who opened the request to remove the Flatpak in addition to ours) manages the RPM, and we do not, and have not, ever had any issues with the RPM which is packaged properly.
With that in context, I'd like to believe while still a bit hostile, it was necessary since they really didn't care about what's being asked here.
Which seems pretty reasonable to me, so I can't really fault OBS here.
flatpak remote-add --if-not-exists fedora oci+https://registry.fedoraproject.org- upstream maintainer: too much work. each distro requires certain best practices/convention.
- distro: may not meet certain standard set by upstream maintainer.
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.
https://en.m.wikipedia.org/wiki/Debian%E2%80%93Mozilla_trade...
3. Trademarks never expire, unlike patents, trade secrets, etc. Unlike source code, the trademark owner has near-absolute leeway in how they are used.
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.
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.
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.
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.
Downstream can have their own package either way, as long as it’s marked as unofficial.
I'm not sure I'd call that a fiasco, and
https://en.wikipedia.org/wiki/Cdrtools#License_compatibility...
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".
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.
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.
switched to ubuntu for desktop and debian for server in 2006 for my company, by 2020 most developers chose mac for desktop and debian/ubuntu for server
Basically it demands that the FlatPak be removed from the repository citing "problems" that aren't detailed. Then 22 days later they start throwing bombs on their own gitlab (again, without details about what the problems with the FlatPak) and get those posted to HN?
Lots of steam, no meat. If this did go to a lawyer, the first question would be "Well, did you try to work with them?" Seemingly the answer is no. Or if it's "yes", it's somewhere back in the history of a pre-existing conflict.
This isn't the first conflict between an upstream and a distro about packaging process and it won't be the last. By definition the feature we users want from the distros is that they are making opinionated choices about how to present the world of software to us.
https://pagure.io/fedora-workstation/issue/463#comment-95541...
Basically, the discussion somehow got turned into berating the OBS team for relying on an EOL runtime (which, as they carefully explain, was due to regressions when upgrading). I assume that waiting three weeks for any sort of movement and then getting insults in return is what caused them to reach for the nuclear option.
This is basically the same conflict between upstreams and distro developers that has been raging since time immemorial.