Ah, Linux, you gotta love it right? There's numerous different ways to do the same thing. One of those that people like to argue about is packaging and how to install things on Linux. Flathub with Flatpaks at least seem to be popular and it keeps growing.
Cassidy James Blaede just wrote up an official blog post going over some numbers, and it's quite impressive to see. To date it shows that Flathub has served just about 1.6 billion downloads, has over 2,400 apps (850 of which are Verified by the author) and there's now over 1 million active users too. Their public dashboard has some pretty fun stats.
One of the big reasons for the growth no doubt is the Steam Deck, which has a full KDE Plasma desktop mode in SteamOS, and has Flathub for all the extra apps and games you can install. A point that was touched on in the blog post noting that some of the most popular downloads on Flathub are emulators and game launchers.
It's not just Steam Deck though with Flathub being included out of the box across the likes of Clear Linux, Endless OS, KDE Neon, Linux Mint, Pop!_OS, and Zorin OS and Fedora 38.
I think Flathub is great personally, it's often made it far easier to tell people where to grab something that's actually up to date. Telling people "it's on Flathub, install via GNOME Software or KDE Discover" makes Linux a lot easier.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
Quoting: razzeQuoting: LoudTechieQuoting: razzeQuoting: slaapliedjeQuoting: Purple Library GuyQuoting: ElectricPrismI've long thought that one of the most potentially important things about Flatpaks is about closed, mostly non-game software. That stuff can't be packaged by your distro, so the ability for vendors to build their stuff in a fairly easy, pretty solid, distro-agnostic way could go a long way towards reducing complaints about Linux fragmentation.QuoteFlathub has served just about 1.6 billion downloads, has over 2,400 apps
Very impressive, congratulations to @all. The quality of FOSS on the store is great, and while predicting the future is hard -- I am modestly optimistic about their efforts to make a commercial area of the store someday.
It is this! Flatpak shouldn't be used to replace the distributuion software. The reason why is that it is tightly integrated and you will have security updates and bug reports you can send to your distro. The vast majority if Flatpaks are not officially packaged by the upstream project, and cannot be easily verified they haven't been messed with.
Why can't they be verified? And how can you verify a distro package?
The answer is(ofcourse) multiple ways.
The GNU, Linux, bsd, FOSS, etc. security model is build heavily on source code availability and subsequent peer review.
One way to verify is with reproducible builds. Build a package the advised way and hash it and compare it to the hash of the binary package.
A second way is with signature checks. This could work given that you've a party that you trust to produce a trustworthy indication of which developers produce trustworthy proprietary code. This is uncommon under developers of FOSS associated projects(self selecting), so there aren't a lot of tools for it. Also it is hard to generalize, because that trust is a lot more variable in a world of a thousand distros than one Microsoft/Sony/Apple.
This is how basic distro security works. The distro maintainer signs their package and you check if the signature matches theirs. This doesn't work, because distro maintainers have no way to distinguish modified proprietary packages from non-modified ones and because they simply never trust proprietary packages.
A third way is with self compiling and source code checks(this is how the distro maintainers do it themselves).
So flathub is at least doing 1. And 3 is done but by the app author. I'm very unsure if distro maintainers actually do it, tbh I don't believe that.
Flathub doesn't do 1, because they've nothing to compare the hash against. They only got the binary package provided by the uploader who may or may not be the developer and to fit into a flatpak the binary file probably had to be different anyway.
The app author does indeed number 3, but that doesn't help, because they can't scalable proof they're the author(s) to flathub, he isn't necessarily a trusted actor and nobody else can check their work.
Explanations of the statements in the summary:
The spoilers are examples.
"they can't scalable proof they're the author(s) to flathub"
It's really easy to claim you wrote a piece of software when you didn't. It's even easier to claim you wrote software with an arbitrary name when you didn't.
Spoiler, click me
"I wrote Photoshop here you got it and no it's not a cracked version of photoshop with a cryptominer embedded in it. Why would you even think that?"
If the author can compile and read their program without it raising alarms to them it means they think it does what they want, but if they want malicious things it's still an issue.
Spoiler, click me
"I wrote a cool app that allows you to achieve Nirvana and no it isn't just a random yellow circle generator with ransomware embedded in it. Why would you even think that?".
"nobody else can check their work"
The fact that the author of a program can compile and read a program doesn't mean it's not a virus. The fact that someone else can compile and read a program without concluding that it's a virus means it at least has been hidden well and indicates that it's not virus.
Spoiler, click me
"I wrote a cool app that allows you to achieve Nirvana and no it isn't just a random yellow circle generator with ransomware embedded in it. No you can't see what it's doing."
The trick of flathub is twofold:
A. they render verification of lesser importance by placing the program in a sandbox, so that if it's malicious it can only inflict harm through direct user interaction.
and
B. they use the second method to try and become that one party for providing trusted proprietary code
(this is better verification than it looks, because if the market comes to agree with them that they're such a trusted provider, they will start providing unscalable verfication and proof of ownership through by flathub trusted actors(lawyers, judges, investigators and notaries)).
Also the way flatpak works allows for a 4th method of verification that used to only comfortably work with foss applications, which I forgot to provide.
Logging
By keeping track of what a program is doing one can catch generic malware and/or reverse engineer any form of software.
This is actively battled by both malware and proprietary authors by obfuscating what the software is doing, but flatpak puts enough restrictions on how the software may function that de-obfuscating and logging behavior becomes a lot easier.
A distro maintainer has to do 3 at a certain level, because getting something to work with a package manager means obtaining a full list of relevant dependencies and declaring them in the package.
If the source code is available compiling it on a bare system is really the fastest way of doing this(unless the original programmers have kept track of all the dependencies, but that's very rare).
Also self compiling is more normal under people with programming skills(like distro maintainers) than you might think. Ask Linux_rocks or any of the old timers on this forum. Gentoo used to require self compilation of everything and had still thousands of users.
Having said that after two or three layers of downstream most packages have the full list and compiling is still more work than copying, so you're right that not all of them use method 3 all the time.
Also my excuses for the long post.
I wasn't fully certain what exactly you meant with your post, so I provided all the information and explanation needed for all the interpretations I could come up with.
Last edited by LoudTechie on 30 January 2024 at 4:47 pm UTC
0 Likes
I'm still really confused by what your saying. Currently every app that gets published to flathub needs to have sources available online and have the manifest pushed to their github.
Sure, binaries are sources too, but that's actually something flathub doesn't like to see, as it mostly means no ARM builds/support, as people usually don't care to provide binaries for both.
Then everything is build on flathub bulidbot in a sandboxed/offline environment https://buildbot.flathub.org/ so you need to grab sources first. So what you commited to your manifest, can't be changed after the fact, as you also need to provide hash sums for all downloads and they get checked - so that you can't change them after pushing the manifest.
The verification of authors of flathub packages currently work via domains, so if you install tv.kodi.Kodi and it's verified, you can be sure, that someone having access to kodi.tv is involved.
Sure, binaries are sources too, but that's actually something flathub doesn't like to see, as it mostly means no ARM builds/support, as people usually don't care to provide binaries for both.
Then everything is build on flathub bulidbot in a sandboxed/offline environment https://buildbot.flathub.org/ so you need to grab sources first. So what you commited to your manifest, can't be changed after the fact, as you also need to provide hash sums for all downloads and they get checked - so that you can't change them after pushing the manifest.
The verification of authors of flathub packages currently work via domains, so if you install tv.kodi.Kodi and it's verified, you can be sure, that someone having access to kodi.tv is involved.
0 Likes
Quoting: razzeI'm still really confused by what your saying. Currently every app that gets published to flathub needs to have sources available online and have the manifest pushed to their github.A. sorry for the late reaction. I didn't get a notification.
Sure, binaries are sources too, but that's actually something flathub doesn't like to see, as it mostly means no ARM builds/support, as people usually don't care to provide binaries for both.
Then everything is build on flathub bulidbot in a sandboxed/offline environment https://buildbot.flathub.org/ so you need to grab sources first. So what you commited to your manifest, can't be changed after the fact, as you also need to provide hash sums for all downloads and they get checked - so that you can't change them after pushing the manifest.
The verification of authors of flathub packages currently work via domains, so if you install tv.kodi.Kodi and it's verified, you can be sure, that someone having access to kodi.tv is involved.
B. You seem to know more about the way flathub works than me, so when in doubt assume that I'm wrong.
C. According to your story they verify if something matches its git release with indeed hash checking.
D. A verification purist would argue that doesn't help for binary only releases, because for binary only releases it only proofs that the git and the flathub contain the same possible malware, but there is still no to the binary relatable claim other than the binary(which nobody, but the publisher is supposed to be able to check) over what it does.
D.1. I said "they've nothing to compare it against". With that I meant that they had
E. The work through domains is in essence trick 2.
You can be very certain that the one who uploaded your software uploaded the same stuff they uploaded on git, but what they uploaded to both is an open question for binaries.
Still this is better verification than some might think.
Most if not all of this stuff is uploaded on github and github is enough of a central party that people actively check their website for them for malware(github stars and reporting).
Last edited by LoudTechie on 6 February 2024 at 5:40 pm UTC
0 Likes
slaapliedje Feb 7
Quoting: LoudTechieAgreed. There are edge cases I've seen, like Discord, for example. They are absolutely not the ones who upload Discord to flathub, and they recommend using their .deb package. Discord is very weird on how they manage their updates. Instead of doing what a lot of people who build .deb files have done, which is give you a repo to add in /etc/apt/sources.list.d/, they just have a .deb package you are prompted to download when there's an update... and then on top of that .deb package, it pulls in other updates... It's very odd.Quoting: razzeI'm still really confused by what your saying. Currently every app that gets published to flathub needs to have sources available online and have the manifest pushed to their github.A. sorry for the late reaction. I didn't get a notification.
Sure, binaries are sources too, but that's actually something flathub doesn't like to see, as it mostly means no ARM builds/support, as people usually don't care to provide binaries for both.
Then everything is build on flathub bulidbot in a sandboxed/offline environment https://buildbot.flathub.org/ so you need to grab sources first. So what you commited to your manifest, can't be changed after the fact, as you also need to provide hash sums for all downloads and they get checked - so that you can't change them after pushing the manifest.
The verification of authors of flathub packages currently work via domains, so if you install tv.kodi.Kodi and it's verified, you can be sure, that someone having access to kodi.tv is involved.
B. You seem to know more about the way flathub works than me, so when in doubt assume that I'm wrong.
C. According to your story they verify if something matches its git release with indeed hash checking.
D. A verification purist would argue that doesn't help for binary only releases, because for binary only releases it only proofs that the git and the flathub contain the same possible malware, but there is still no to the binary relatable claim other than the binary(which nobody, but the publisher is supposed to be able to check) over what it does.
D.1. I said "they've nothing to compare it against". With that I meant that they had
E. The work through domains is in essence trick 2.
You can be very certain that the one who uploaded your software uploaded the same stuff they uploaded on git, but what they uploaded to both is an open question for binaries.
Still this is better verification than some might think.
Most if not all of this stuff is uploaded on github and github is enough of a central party that people actively check their website for them for malware(github stars and reporting).
0 Likes
redneckdrow Feb 7
Quoting: slaapliedjeQuoting: redneckdrowThe recent Tales & Tactics malicious update in Steam, thanks to their discord being compromised, is a good reason why updates should be checked before install. Admittedly, the devs fixed that pretty quickly, before the Winter update. Thank God I checked the forum when I couldn't find release notes at the time.Huh, what happened with this? How does getting their discord compromised lead to a malicious update on Steam?
It happened with their Downfall mod for Slay the Spire too. Were I a betting man, I'd say they used the same password for both accounts.
Here's the info at the time:
Spoiler, click me
UPDATE 12/29 - While there is no new alerts regarding the Steam product or risk of downloads, the Discord account remains compromised. I have reports that the account is trying to DM people and either send malware to them impersonating themselves as a developer, or trying to gain sensitive information. Do not engage with this account and absolutely do not click on any links sent.
(Update 7:19 PM Eastern 12/27, 0020 UTC+0 12/28) - We just updated the game intentionally, switching to a fresh clean depot for future use. Do not be alarmed if you see an automatic update.
Hello everyone. I bring some unfortunate news today. Yesterday, Christmas Day, at roughly 12:30 PM Eastern time, we experienced a security breach. At roughly 1:20 PM (1820 UTC+0 on 25/12) , that breach allowed a malicious upload to overtake our game on Steam's library for a period of roughly one hour. Our steam and discord accounts were hijacked, and though the Steam accounts were able to be recovered late in the evening, we were limited in our ability to warn or communicate immediately following the breach. Fortunately, we were able to contain the actual breach much more quickly than the amount of time it took to recover the accounts. The important parts you need to know are:
-The breach window was roughly 1:30 PM-2:30 PM Eastern (1830-1930 UTC+0) on 12/25.
-Downfall is safe to launch once more, and has been since roughly 2:30-2:40 PM Eastern on 12/25 (1920 UTC+0 on 12/25).
-If you did not launch Downfall in the breach window, you're clear.
-If you got an automatic update for Downfall on 12/25 but did NOT launch, you're clear.
-If you launched Downfall via the Steam Workshop (meaning you actually launched Slay the Spire), you're clear.
-If you did launch Downfall on 12/25 and succeeded and everything looked normal, you're clear.
-If you did launch Downfall on 12/25 and saw a command-prompt like screen, that starting spitting out a bunch of text after about 10 seconds, you're in the clear. That was actually just the Java log which we usually keep hidden, but accidentally left visible when we restored the game.
-If you did launch Downfall on 12/25 and got a 'no .exe found' type of error, you're clear. That was us exploding the game to prevent anyone else from being affected.
-If you did launch Downfall on 12/25 during the breach window and got a Unity library installer popup, please continue to read. You may be also at risk.
The security breach allowed a malicious upload to replace the Downfall packaged game. If you were one who saw that Unity library popup, here is the information we have at this time involving the malware that may have affected you:
Most Antiviruses seem to have not stopped the malware specifically from executing, but do stop its payload from being sent across the internet. This means you aren't automatically damaged by the attack.
The payload it tries to scrape and generate involves passwords, specifically from your browsers, Discord, and a few other applications: Windows local login, Google Chrome, Yandex, Microsoft Edge, Mozilla Firefox, Brave, Vivaldi, Telegram, Discord, and files that might contain the word 'password' (if 'password' is in the filename).
If you saw the Unity popup or otherwise feel you may be breached, we recommend you changing important passwords, particularly ones that are not set up for 2FA (2-factor authentification). Any account that is set up for mobile 2FA should be immune. You should also be sure your live protection is active and run scans. Though, for full peace of mind, I personally am electing to reset and wipe all of my drives from my affected hardware.
The payload included the installation of a "WindowsBootManager as an application under my user's AppData folder. Also "Windows Boot Manager is a video game".
One user reported: In your users/[username]/AppData/Local/Temp folder, there will be several files the Trojan creates. One will be called epsilon-[username].zip, which contains everything the Trojan has stolen -- Discord info, autocomplete, saved passwords, network info, cookies, saved credit cards, steam info. WARNING: If you go investigating these files for yourself, to do so without being connected to the internet, just in case there is still some possibility of retriggering an event.
Another user reports: "It was under Local\microsoft\windows\0 for me. It said it was a video game, and from a name i didnt know. I checked on another computer on windows 11 and this file didnt exist. I deleted it and i had no problem restarting the computer afterward, but it was scary.
The other file was named unitylibmanager and was found under local\temp\ and i think this one was the original offender.
I also had a problem with Discord, can't say it was linked but it said the .exe was infected, so i deleted everything."
Also can confirm: "I found WindowsBootManager as an application under my user's AppData folder. Also "Windows Boot Manager is a video game" lmao. I deleted all of them manually."
(UPDATE 12.27.23 2:29 AM) Another user has reported: it looks like in my (user)/AppData/Roaming folder there is a folder named 'UnityLibManager' which was created at the time of all the other malicous folders/files and that was what windows defender detected ('UnityLibManager.exe')
We are still working with any affected users to gather and share as much data as we possibly can. We are also communicating with Valve on the nature and timing of the breach so they can also help from their end.
For those concerned about future breaches, we purged the affected hardware that was breached completely, a full hard drive wipe. We've also added additional security and are in the process of transferring ownership of Downfall to a dedicated Steam account that solely is responsible for uploading to it and is never used or logged in for any other purpose. As much as we like to think we're safe, the reality is that any account that is actively used (that is, logged into frequently) is always at risk to a malware attack, and in this case, Downfall was owned by an active account. When that active account become compromised, so did Downfall. The act of the account being logged in at all was all that was needed for the breach to happen in this case.
I can't apologize enough to the affected users. The thought that someone would hijack a free passion project for malicious intent is truly vile. Downfall is nothing without its players and the joy surrounding it and I am appalled at the attack.
Thank you all for your understanding. I will continue to update as any more information comes my way.
-Michael Mayhem
2 Likes, Who?
Patreon
PayPal
See more from me