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.
I went from a flatpak vocal sceptic to a regular user and supporter. I like having that much non-free modern software at hand. Can't find where I can support flathub monetarily though. The repo maintainers deserve our full support.While I don't agree with you about parties spreading non-free software in desktop GNU/Linux deserving full support, here's the donation link of flathub https://flathub.org/donate for those who agree with you.
Last edited by LoudTechie on 29 Jan 2024 at 11:02 am UTC
Unfortunately there will always be non-free software. While the ultimate idea of RMS was that even games would be open source, and in essence you'd just pay for the graphics / sounds assets is great, only a few projects have made that a reality (like OpenMW, the Doom engines, etc.)I went from a flatpak vocal sceptic to a regular user and supporter. I like having that much non-free modern software at hand. Can't find where I can support flathub monetarily though. The repo maintainers deserve our full support.While I don't agree with you about parties spreading non-free software in desktop GNU/Linux deserving full support, here's the donation link of flathub https://flathub.org/donate for those who agree with you.
I think of Flathub more of a solution for the various package formats. But as I said earlier, flatpaks aren't always made by the upstream project (like Firefox is, but Discord is not) and using some of these can be bad, as people can modify things to put up there.
This is also why the various GUIs for flatpak have warnings on the page.
The 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?
Unfortunately there will always be non-free software. While the ultimate idea of RMS was that even games would be open source, and in essence you'd just pay for the graphics / sounds assets is great, only a few projects have made that a reality (like OpenMW, the Doom engines, etc.)I went from a flatpak vocal sceptic to a regular user and supporter. I like having that much non-free modern software at hand. Can't find where I can support flathub monetarily though. The repo maintainers deserve our full support.While I don't agree with you about parties spreading non-free software in desktop GNU/Linux deserving full support, here's the donation link of flathub https://flathub.org/donate for those who agree with you.
I think of Flathub more of a solution for the various package formats. But as I said earlier, flatpaks aren't always made by the upstream project (like Firefox is, but Discord is not) and using some of these can be bad, as people can modify things to put up there.
This is also why the various GUIs for flatpak have warnings on the page.
True there will always be proprietary software, but
A. That doesn't mean I'm a fan of actively paying for distributing it. If proprietary is so profitable as is often claimed those writing it can pay someone to distribute it from their profits.
B. That doesn't mean it has to come this close to home as to be spread through the software stores in desktop Linux systems.
I don't think flatpack will serve as a fix for package standard proliferation. I think it will just add another package format.(xkcd 927)
My experience with standardization is as such. Only large parties can instantiate a standard. Large consumers tend to prefer open standards, large sellers tend to prefer proprietary standards.
That having said I think flatpack will bring something good.
I expect that much like SElinux it will strengthen the GNU/Linux reputation of being really secure and that this time the security will be useful for more parties than large organizations with a clear hierarchy and taking software freedoms.
Last edited by LoudTechie on 29 Jan 2024 at 5:03 pm UTC
The key take away here is that flatpak is an OPEN standard, vs Snap, which only Ubuntu can run a 'store'. There is definitely a time and place for 'paid' apps, like say Steam has for Games. Though in all honesty, there are so many open source programs out there that would be perfectly fine to replace proprietary stuff (like office suites, for example).Unfortunately there will always be non-free software. While the ultimate idea of RMS was that even games would be open source, and in essence you'd just pay for the graphics / sounds assets is great, only a few projects have made that a reality (like OpenMW, the Doom engines, etc.)I went from a flatpak vocal sceptic to a regular user and supporter. I like having that much non-free modern software at hand. Can't find where I can support flathub monetarily though. The repo maintainers deserve our full support.While I don't agree with you about parties spreading non-free software in desktop GNU/Linux deserving full support, here's the donation link of flathub https://flathub.org/donate for those who agree with you.
I think of Flathub more of a solution for the various package formats. But as I said earlier, flatpaks aren't always made by the upstream project (like Firefox is, but Discord is not) and using some of these can be bad, as people can modify things to put up there.
This is also why the various GUIs for flatpak have warnings on the page.
True there will always be proprietary software, but
A. That doesn't mean I'm a fan of actively paying for distributing it. If proprietary is so profitable as is often claimed those writing it can pay someone to distribute it from their profits.
B. That doesn't mean it has to come this close to home as to be spread through the software stores in desktop Linux systems.
I don't think flatpack will serve as a fix for package standard proliferation. I think it will just add another package format.(xkcd 927)
My experience with standardization is as such. Only large parties can instantiate a standard. Large consumers tend to prefer open standards, large sellers tend to prefer proprietary standards.
That having said I think flatpack will bring something good.
I expect that much like SElinux it will strengthen the GNU/Linux reputation of being really secure and that this time the security will be useful for more parties than large organizations with a clear hierarchy and taking software freedoms.
The key take away here is that flatpak is an OPEN standard, vs Snap, which only Ubuntu can run a 'store'. There is definitely a time and place for 'paid' apps, like say Steam has for Games. Though in all honesty, there are so many open source programs out there that would be perfectly fine to replace proprietary stuff (like office suites, for example).Unfortunately there will always be non-free software. While the ultimate idea of RMS was that even games would be open source, and in essence you'd just pay for the graphics / sounds assets is great, only a few projects have made that a reality (like OpenMW, the Doom engines, etc.)I went from a flatpak vocal sceptic to a regular user and supporter. I like having that much non-free modern software at hand. Can't find where I can support flathub monetarily though. The repo maintainers deserve our full support.While I don't agree with you about parties spreading non-free software in desktop GNU/Linux deserving full support, here's the donation link of flathub https://flathub.org/donate for those who agree with you.
I think of Flathub more of a solution for the various package formats. But as I said earlier, flatpaks aren't always made by the upstream project (like Firefox is, but Discord is not) and using some of these can be bad, as people can modify things to put up there.
This is also why the various GUIs for flatpak have warnings on the page.
True there will always be proprietary software, but
A. That doesn't mean I'm a fan of actively paying for distributing it. If proprietary is so profitable as is often claimed those writing it can pay someone to distribute it from their profits.
B. That doesn't mean it has to come this close to home as to be spread through the software stores in desktop Linux systems.
I don't think flatpack will serve as a fix for package standard proliferation. I think it will just add another package format.(xkcd 927)
My experience with standardization is as such. Only large parties can instantiate a standard. Large consumers tend to prefer open standards, large sellers tend to prefer proprietary standards.
That having said I think flatpack will bring something good.
I expect that much like SElinux it will strengthen the GNU/Linux reputation of being really secure and that this time the security will be useful for more parties than large organizations with a clear hierarchy and taking software freedoms.
Oh, I agree with the the statement that it will snap snap.
I just don't think it will(or should) make a dent in package proliferation, because it won't do anything to .deb, .rpf, appimage, etc.
Also we're having a miscommunication and that is my fault.
I use the term free, but I didn't mean free as in 0 cost, but free as in freedom(basically open source).
Inkscape has long been unknown to many Linux users paid software, just also open source. If you wanted to obtain it from the Microsoft store you had to pay a small fee to a central party defending the goals of the developers(including paying them directly, but not only that) the SFC.
Paid software has its place inside the ecosystem and I have nothing against distributing and helping paid software.
I argued that helping distribute non-open source software was something I can't actively
I kind of look at the potential of having 'pay for' software in Flathub to be somewhat of a benefit, because then there could be a percentage of the purchase of software to fund improvements to other open source software.The key take away here is that flatpak is an OPEN standard, vs Snap, which only Ubuntu can run a 'store'. There is definitely a time and place for 'paid' apps, like say Steam has for Games. Though in all honesty, there are so many open source programs out there that would be perfectly fine to replace proprietary stuff (like office suites, for example).Unfortunately there will always be non-free software. While the ultimate idea of RMS was that even games would be open source, and in essence you'd just pay for the graphics / sounds assets is great, only a few projects have made that a reality (like OpenMW, the Doom engines, etc.)I went from a flatpak vocal sceptic to a regular user and supporter. I like having that much non-free modern software at hand. Can't find where I can support flathub monetarily though. The repo maintainers deserve our full support.While I don't agree with you about parties spreading non-free software in desktop GNU/Linux deserving full support, here's the donation link of flathub https://flathub.org/donate for those who agree with you.
I think of Flathub more of a solution for the various package formats. But as I said earlier, flatpaks aren't always made by the upstream project (like Firefox is, but Discord is not) and using some of these can be bad, as people can modify things to put up there.
This is also why the various GUIs for flatpak have warnings on the page.
True there will always be proprietary software, but
A. That doesn't mean I'm a fan of actively paying for distributing it. If proprietary is so profitable as is often claimed those writing it can pay someone to distribute it from their profits.
B. That doesn't mean it has to come this close to home as to be spread through the software stores in desktop Linux systems.
I don't think flatpack will serve as a fix for package standard proliferation. I think it will just add another package format.(xkcd 927)
My experience with standardization is as such. Only large parties can instantiate a standard. Large consumers tend to prefer open standards, large sellers tend to prefer proprietary standards.
That having said I think flatpack will bring something good.
I expect that much like SElinux it will strengthen the GNU/Linux reputation of being really secure and that this time the security will be useful for more parties than large organizations with a clear hierarchy and taking software freedoms.
Oh, I agree with the the statement that it will snap snap.
I just don't think it will(or should) make a dent in package proliferation, because it won't do anything to .deb, .rpf, appimage, etc.
Also we're having a miscommunication and that is my fault.
I use the term free, but I didn't mean free as in 0 cost, but free as in freedom(basically open source).
Inkscape has long been unknown to many Linux users paid software, just also open source. If you wanted to obtain it from the Microsoft store you had to pay a small fee to a central party defending the goals of the developers(including paying them directly, but not only that) the SFC.
Paid software has its place inside the ecosystem and I have nothing against distributing and helping paid software.
I argued that helping distribute non-open source software was something I can't actively
Imagine if Flathub did a 'OSS Software of the Month' selection, that was voted on each month for the next month (so a poll would run through January for February's software) and during that month, proceeds from any 'pay for' software percentage would go to the developers of that piece of software. Even if they did a percentage of a percentage (like say they take 30% of Photoshop profits, then take 25% of that for the Software of the Month and then 5% goes to the development / services for Flathub). Would be a great way to turn funds from proprietary software into funds for open source software!
I recall having issues when one library or dependency would be too new and it was either - wait , or start messing with simlinks etc.
I know it's not a fault of AUR in itself but of the packages i was using and maybe my impatience , but I have to say flatpak is a lot more convenient to download , update and use.
I'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.Flathub 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.
I'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.Flathub 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
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
"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
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 Jan 2024 at 4:47 pm UTC
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.
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.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 Feb 2024 at 5:40 pm UTC
Agreed. 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.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.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).
The 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
See more from me