4 ms·

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 al

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.

worble 2y ago
From what I can tell reading the pagure.io thread (https://pagure.io/fedora-workstation/issue/463#comment-955418 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.
- jcelerier 2y ago
  > 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.
  - comex 2y ago
    I would differentiate your scenario in five ways. 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.
    - jcelerier 2y ago
      > 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
      - daurentius523 2y ago
        "Qt is only used for the GUI in OBS." - I don't think that QObjects : OAuth, TwitchAuth and YoutubeAuth are gui related.
- mappu 2y ago
  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.
- finnthehuman 2y ago
  >the claim from Fedora is 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.
ddtaylor 2y ago
Flatpak doesn't cover all use cases. This is an area where Wayland adoption has been complex. Many people still need the regular version.

worble 2y ago

From what I can tell reading the pagure.io thread (https://pagure.io/fedora-workstation/issue/463#comment-955418 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.

jcelerier 2y ago
> 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.
- comex 2y ago
  I would differentiate your scenario in five ways. 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.
  - jcelerier 2y ago
    > 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
    - daurentius523 2y ago
      "Qt is only used for the GUI in OBS." - I don't think that QObjects : OAuth, TwitchAuth and YoutubeAuth are gui related.
mappu 2y ago
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.
finnthehuman 2y ago
>the claim from Fedora is 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.

ddtaylor 2y ago

Flatpak doesn't cover all use cases. This is an area where Wayland adoption has been complex. Many people still need the regular version.