Good to see one of the two big packaging hubs do something against malware
Next step, display the "potential unsafe"-badge next to verified or unverified, that can be found on the same page. In example https://flathub.org/apps/io.github.shiiion.primehack is marked as verified, but if you scroll down you can see the application has full system and data access and is marked as potential unsafe.
cough cough snap cough
Snap already marks unverified apps
Yet Ubuntu still recommends installing anything from the terminal if a command was found in a rando unverified snap.
How does that Help against Malware?
It makes it obvious to people whether they are downloading Google Chrome as packaged by Google or as by someone else. That being said, Google Chrome is malware. That being said there is a lot more that needs to be done to truly prevent malware, which will be costly but will hopefully take effect when they've got the budget for it
Because if you search Firefox and see a badge that says verified, you can be confident that it was Mozilla that packaged it and added it to FlatHub as opposed to some random scammer.
You can't just upload a App to Flathub. Everythng is reviewed.
Apt has done this forever
Verification doesnt help at all if the source is not trusted. All this says is "upstream developers maintain this package". Unofficial packages can be safe too, like VLC.
This is a good step but I still feel like it's pretty obscure where a package is actually coming from. "by Google" or for the Steam package "by Valve" is really confusing and makes it sounds like it's coming directly from the company. Unverified tells the user to pay attention but there is no hover over to say what it actually means.
Wait… so the author displayed in “by ” is the supposed author of the software, not the one that put it on the store? That’s insane! Also sounds like you’d be open to massive liability since the reputation of the software author will be damaged if somebody publishes malware under their name.
Also maaany packages direct to issuetrackers of projects not supporting that flatpak.
If someone knows where that flathub metadata is stored I would love to know, as the manifest is not it. I would like to fix those to link to their own bugtrackers
Traditional GNU/Linux distributions (as well as F-Droid) are not "app stores" even though they are superficially similar. Traditional distributions are maintained and curated by the community, and serve the interests of users first and software developers second, whereas an "app store" has minimal curation and serves the needs of software developers first and users second.
I point this out because there's an annoying meme that traditional distributions are obsoleted by the "app store" model. I don't think that's the case. "Verification" is essential for an app store but pointless for a distribution.
So all of them?
Would be nice if FlatHub actually supported cryptographic verification of apps..
Flathubs repository’s is GPG signed.
Nope. Link me to the docs that say this.
The GPG key is literally in the repo file https://dl.flathub.org/repo/flathub.flatpakrepo
Lol that's not for signing the packages
There is no such thing as a “package”. It is a repository of binary data with references to data in it (ala git). The whole repo and all data is gpg signed.
Your claim that package payloads are signed is bullshit. Back it up by citing your sources
> ostree show flathub:runtime/org.kde.Platform/x86_64/6.6
commit a7443e846cf67d007fcecda5c9dc27844001cfb8929064395cfc25c6d71d9474
Parent: 23107550082daf3b2892a4a0db2543838578ca882340a756b988bc5c1614540c
ContentChecksum: 607ba9475d32a24c51509bc7919f5a93d401f8f7198c30ad93ad74051d966c41
Date: 2024-01-30 13:55:08 +0000
build of org.kde.Sdk, Tue Jan 30 11:23:00 UTC 2024 (5998d2f3ef21414d14f066ab91fa44e5aef65b90)
Name: org.kde.Platform
Arch: x86_64
Branch: 6.6
Built with: Flatpak 1.14.4
Found 1 signature:
Signature made Tue 30 Jan 2024 12:21:18 PM CST using RSA key ID 562702E9E3ED7EE8
Good signature from "Flathub Repo Signing Key "
Primary key ID 4184DD4D907A7CAE
Key expires Mon 14 Jun 2027 08:19:40 AM CDT
Primary key expires Mon 14 Jun 2027 08:18:56 AM CDT
And what happens if I mitm you and you get something unsigned? Does it ignore it and proceed?
This is why in asking for the docs that describe the security
GPG errors are fatal unless you manually configure the repo to ignore them with an obscure command.
Please link to the docs
great, when appimage hub begin doing this
I still don't understand why a central repository for AppImages exist. The moment you are using a repository (and possibly version management), the format looses its reason to exist.
I don't see how that's true. The main point of AppImage is it 'just works' on any distro. If you have one primary place to distribute them to any distro - it's still meeting AppImage's vision.
To be fair, after some thinking I think you are right and I was a bit in a tunnel vision logic. My previous statement looks a bit foolish now.
No. Appimages are selfcontained and thus useful for archiving software or carrying it around in random ways. Flatpak could do this too but not as easy.
I personally use a few AppImages, but want replace them with Flatpaks. Flatpaks have their own issues, and because I did not want to troubleshoot in case I encounter another issue, just carry on using AppImages for these selected applications. Also I was not able to archive Flatpak easily, its very complicated with keys and not. Compared to it, I just have the AppImages included in my regular backup process with regular files.
My point was not if AppImages are useful (they clearly are and I use them), but was talking bout repositories. However after some other replies I thought about it and indeed such a repository makes sense even for AppImages. I personally just don't have to use them.
Even with such a repo they are highly insecure by design.
Not really. AppImages are as much secure as any other executable you run on your system. If you download it from a trusted source, like you download trusted Flatpaks or your systems repository, then they are not worse. If you say AppImages are highly insecure, because you run executable code, then you have to take that logic to any other executable format. The problem is not the format itself that makes it insecure, it's the source.
No they arent. Please read the linked post.
I read that page and there is nonsense included too. Just because I read that page does not make it correct. If you think that AppImages insecure, then you did not understand my point that its not the format thats insecure, but the source where you get the files. Every packaging system is insecure if you get it from bad source.
That's not even a question. AppImages are fine and not insecure if you download it from a secure place you trust (like your system packages, you trust your distro maintainer fully). Would you trust every distribution maintainer on every distribution? Let's say a Chinese Linux distribution, that maintains Flatpaks and native packages. Let's say they are flaky. See? It's the source you don't trust, not the file format or packaging system.
Read my replies (just like you said I should read the linked post). And understand the issues.
Shit missing internet got my comment deleted...
Appimage is not a neutral packaging format. Of course "an app packaged as .zip is as secure as packages as .tar.gz". But the format causes all the things mentioned in the post.
libraries are often the oldest non-EOL possible to support old kernels
no transparency about used libraries and possible vulnerabilities
no upgrades of libraries, always just the wanted app and then passively also the libraries
no sandboxing without firejail (which is a root binary and thus can lead to privilege escalation of rootless processes if it has a vulnerability which it had in the past)
no GUI sandboxing
even with a repo no cryptographic signature verification like on Android (not sure about Flatpak which uses OSTree)
requires users to execute code in random locations
So it is way less secure than Flatpak, thats a fact. It may not be worse than tarballs, but if those dont include the libraries even less secure than them.
I partly agree. But your tone changed a lot from "highly insecure" to "less secure", which is a complete different statement. An application does not need to be in a sandbox to be secure, so I don't accept that as an argument against trusted applications. I only accept your arguments if we talk about random downloads from random places.
Also the argumentation that AppImages are usually run from random locations doesn't make them unsecure, it's a feature. BTW I have a dedicated folder where I put them, but that's my personal organization. Did you know that you can unpack an AppImage back to its original folder (like an archive)? You need appimagetool for that.
The only thing I fully agree with you and is a weak spot about the AppImage format is, that it can or will include outdated and not updated libraries (or executables). Which is the point of the format on the one hand, but a curse on the other hand. Normally it is recommended to build on the oldest supported LTS Ubuntu, because of older libc. libc is the root of many problems in Linux (for compatibility).
What app is that GUI from?
This screenshot is from the Flathub website. The only good GUI for Flatpaks...
The only good GUI for Flatpaks…
Ain't that the truth. I don't know why KDE Discover is so sluggish when it comes to Flatpak, it takes me like 10+ seconds to load the landing page and see the popular apps.
And several minutes to update a 10MB app...
what? there's something wrong with your internet
Nah, it's Discover that's shit. Flatpak's CLI works fine.
Seriously why does Gnome software feel so much faster!
First time I've heard someone call Gnome Software fast. In my experience that app feels like it's on it's last legs; the Flatpak CLI is far better than any desktop GUI.
Gnome Software has received numerous updates over the last few years which make it considerable faster. Searching and viewing apps is now fast enough to be usable, compared to it taking many seconds to minutes for basic tasks.
I've stopped removing Software on every system, altough I'm not usually using it. I've not tested it, but I feel like Discover is now slower than Software.
COSMIC Appstore ;D
I'm not saying it's fast; I'm saying that it's faster than KDE Discover
My main issue with Gnome Software is if I queue something to install, and go back to browse for more apps, once something is done installing it "refreshed" and I lose the spot I was at. Makes me feel I can only install one thing at a time.
Likewise with Gnome in my experience. I've been using the CLI but am now realizing I might be missing out on some important information by doing that
It's definitely faster than it used to be. But yeah, searching for app updates is still more sluggish than through the terminal, at least on Fedora Workstation.
Gnome Software is pretty similar. KDE Discover way worse.
Nice
Good to see one of the two big packaging hubs do something against malware
Next step, display the "potential unsafe"-badge next to verified or unverified, that can be found on the same page. In example https://flathub.org/apps/io.github.shiiion.primehack is marked as verified, but if you scroll down you can see the application has full system and data access and is marked as potential unsafe.
cough cough snap cough
Snap already marks unverified apps
Yet Ubuntu still recommends installing anything from the terminal if a command was found in a rando unverified snap.
How does that Help against Malware?
It makes it obvious to people whether they are downloading Google Chrome as packaged by Google or as by someone else. That being said, Google Chrome is malware. That being said there is a lot more that needs to be done to truly prevent malware, which will be costly but will hopefully take effect when they've got the budget for it
Because if you search Firefox and see a badge that says verified, you can be confident that it was Mozilla that packaged it and added it to FlatHub as opposed to some random scammer.
You can't just upload a App to Flathub. Everythng is reviewed.
Apt has done this forever
Verification doesnt help at all if the source is not trusted. All this says is "upstream developers maintain this package". Unofficial packages can be safe too, like VLC.
This is a good step but I still feel like it's pretty obscure where a package is actually coming from. "by Google" or for the Steam package "by Valve" is really confusing and makes it sounds like it's coming directly from the company. Unverified tells the user to pay attention but there is no hover over to say what it actually means.
Wait… so the author displayed in “by ” is the supposed author of the software, not the one that put it on the store? That’s insane! Also sounds like you’d be open to massive liability since the reputation of the software author will be damaged if somebody publishes malware under their name.
It should be:
That was close to my initial suggestion before they ended up choosing choosing this
Also maaany packages direct to issuetrackers of projects not supporting that flatpak.
If someone knows where that flathub metadata is stored I would love to know, as the manifest is not it. I would like to fix those to link to their own bugtrackers
Traditional GNU/Linux distributions (as well as F-Droid) are not "app stores" even though they are superficially similar. Traditional distributions are maintained and curated by the community, and serve the interests of users first and software developers second, whereas an "app store" has minimal curation and serves the needs of software developers first and users second.
I point this out because there's an annoying meme that traditional distributions are obsoleted by the "app store" model. I don't think that's the case. "Verification" is essential for an app store but pointless for a distribution.
So all of them?
Would be nice if FlatHub actually supported cryptographic verification of apps..
Flathubs repository’s is GPG signed.
Nope. Link me to the docs that say this.
The GPG key is literally in the repo file https://dl.flathub.org/repo/flathub.flatpakrepo
Lol that's not for signing the packages
There is no such thing as a “package”. It is a repository of binary data with references to data in it (ala git). The whole repo and all data is gpg signed.
Your claim that package payloads are signed is bullshit. Back it up by citing your sources
And what happens if I mitm you and you get something unsigned? Does it ignore it and proceed?
This is why in asking for the docs that describe the security
GPG errors are fatal unless you manually configure the repo to ignore them with an obscure command.
Please link to the docs
great, when appimage hub begin doing this
I still don't understand why a central repository for AppImages exist. The moment you are using a repository (and possibly version management), the format looses its reason to exist.
I don't see how that's true. The main point of AppImage is it 'just works' on any distro. If you have one primary place to distribute them to any distro - it's still meeting AppImage's vision.
To be fair, after some thinking I think you are right and I was a bit in a tunnel vision logic. My previous statement looks a bit foolish now.
No. Appimages are selfcontained and thus useful for archiving software or carrying it around in random ways. Flatpak could do this too but not as easy.
Still, don't use Appimages
I personally use a few AppImages, but want replace them with Flatpaks. Flatpaks have their own issues, and because I did not want to troubleshoot in case I encounter another issue, just carry on using AppImages for these selected applications. Also I was not able to archive Flatpak easily, its very complicated with keys and not. Compared to it, I just have the AppImages included in my regular backup process with regular files.
My point was not if AppImages are useful (they clearly are and I use them), but was talking bout repositories. However after some other replies I thought about it and indeed such a repository makes sense even for AppImages. I personally just don't have to use them.
Even with such a repo they are highly insecure by design.
Not really. AppImages are as much secure as any other executable you run on your system. If you download it from a trusted source, like you download trusted Flatpaks or your systems repository, then they are not worse. If you say AppImages are highly insecure, because you run executable code, then you have to take that logic to any other executable format. The problem is not the format itself that makes it insecure, it's the source.
No they arent. Please read the linked post.
I read that page and there is nonsense included too. Just because I read that page does not make it correct. If you think that AppImages insecure, then you did not understand my point that its not the format thats insecure, but the source where you get the files. Every packaging system is insecure if you get it from bad source.
That's not even a question. AppImages are fine and not insecure if you download it from a secure place you trust (like your system packages, you trust your distro maintainer fully). Would you trust every distribution maintainer on every distribution? Let's say a Chinese Linux distribution, that maintains Flatpaks and native packages. Let's say they are flaky. See? It's the source you don't trust, not the file format or packaging system.
Read my replies (just like you said I should read the linked post). And understand the issues.
Shit missing internet got my comment deleted...
Appimage is not a neutral packaging format. Of course "an app packaged as .zip is as secure as packages as .tar.gz". But the format causes all the things mentioned in the post.
So it is way less secure than Flatpak, thats a fact. It may not be worse than tarballs, but if those dont include the libraries even less secure than them.
I partly agree. But your tone changed a lot from "highly insecure" to "less secure", which is a complete different statement. An application does not need to be in a sandbox to be secure, so I don't accept that as an argument against trusted applications. I only accept your arguments if we talk about random downloads from random places.
Also the argumentation that AppImages are usually run from random locations doesn't make them unsecure, it's a feature. BTW I have a dedicated folder where I put them, but that's my personal organization. Did you know that you can unpack an AppImage back to its original folder (like an archive)? You need appimagetool for that.
The only thing I fully agree with you and is a weak spot about the AppImage format is, that it can or will include outdated and not updated libraries (or executables). Which is the point of the format on the one hand, but a curse on the other hand. Normally it is recommended to build on the oldest supported LTS Ubuntu, because of older libc. libc is the root of many problems in Linux (for compatibility).
What app is that GUI from?
This screenshot is from the Flathub website. The only good GUI for Flatpaks...
Ain't that the truth. I don't know why KDE Discover is so sluggish when it comes to Flatpak, it takes me like 10+ seconds to load the landing page and see the popular apps.
And several minutes to update a 10MB app...
what? there's something wrong with your internet
Nah, it's Discover that's shit. Flatpak's CLI works fine.
Seriously why does Gnome software feel so much faster!
First time I've heard someone call Gnome Software fast. In my experience that app feels like it's on it's last legs; the Flatpak CLI is far better than any desktop GUI.
Gnome Software has received numerous updates over the last few years which make it considerable faster. Searching and viewing apps is now fast enough to be usable, compared to it taking many seconds to minutes for basic tasks.
I've stopped removing Software on every system, altough I'm not usually using it. I've not tested it, but I feel like Discover is now slower than Software.
COSMIC Appstore ;D
I'm not saying it's fast; I'm saying that it's faster than KDE Discover
My main issue with Gnome Software is if I queue something to install, and go back to browse for more apps, once something is done installing it "refreshed" and I lose the spot I was at. Makes me feel I can only install one thing at a time.
Likewise with Gnome in my experience. I've been using the CLI but am now realizing I might be missing out on some important information by doing that
It's definitely faster than it used to be. But yeah, searching for app updates is still more sluggish than through the terminal, at least on Fedora Workstation.
Gnome Software is pretty similar. KDE Discover way worse.