4 ms·

I think for a store like flathub to be competitive, it should just remove as much friction form the release process as possible. Most upstream developers will l

I think for a store like flathub to be competitive, it should just remove as much friction form the release process as possible. Most upstream developers will likely have their own infrastructure. So, the added value is dubious. And imagine every other store insisted on this, that would add up to a lot of build hassle for developers. And of course not all applications are open source to begin with and a lot of those have a lot of other stores to worry about as well. There are probably very few exclusive Flathub only applications out there. A lot of them are also in Ubuntu's snap store. And then there's the Apple store, the windows store, etc. So, I would recommend to focus on growing the application ecosystem instead of putting up a lot of obstacles and bureaucracy. Make it easy for popular (proprietary and OSS) application developers to target Linux via Flathub. Putting up all sorts of requirements on where and how to build is not helpful for that and likely to make people think twice before bothering with a Flathub release.

vetinari 3y ago
> Most upstream developers will likely have their own infrastructure. So, the added value is dubious. They could make it optional; but the artefacts of those who use it, would be more trustworthy, since flathub can guarantee their BOM. The same way, as you can trust binaries from F-Droid more, than from Google Play.
- gjsman-1000 3y ago
  > The same way, as you can trust binaries from F-Droid more, than from Google Play. Actually, no. I'm forgetting the exact details - but F-Droid (if I recall correctly) re-signs all packages with its own key, removing the developer's signing key. There's some infrastructure reason for it. Google Play keeps that key. This is also why GrapheneOS offers sandboxed Google Play and recommends using that over F-Droid. https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/
  - mook 3y ago
    F-Droid will use your original signatures as long as they can rebuild the binary to be identical (excluding the signature), to verify that everything is open source. They only discard your signatures if they can't confirm that, to avoid issues with hosting proprietary bits. https://f-droid.org/docs/Reproducible_Builds/ https://f-droid.org/docs/Reproducible_Builds/
  - seba_dos1 3y ago
    > but F-Droid (if I recall correctly) re-signs all packages with its own key, removing the developer's signing key The reason why they do that (in some cases) is exactly why F-Droid is more trustworthy than Google Play.
  - piaste 3y ago
    I run GrapheneOS. It's an amazing project, and I always pay attention to what their developers say. But you should keep in mind that the GrapheneOS project is very laser-focused on a certain threat model: aggressively malicious software that tries to exploit vulnerabilities to escape its sandboxes. And they fight against that threat very well (there have been a couple of recent high-profile Android CVEs to which GrapheneOS users were immune). But they are - rightfully - less concerned about the far more common threat of apps including crapload of tracking libraries, battery-burning ads, or dark patterns requesting unnecessary permissions. They provide you with tools to fight them - Storage Scopes and Contact Scopes are amazing! - but ultimately it's up to the user to e.g. choose a serious calculator app like Calculator++ instead of some spyware. And against that threat, it is an excellent idea to search on F-Droid first instead of the Play Store (where the first non-Google, non-Samsung result is indeed an ad-filled spyware calculator). Then, if you want to secure yourself against the possibility of the F-Droid signing keys being compromised, you may choose to delay/disable automatic updates, or simply to download the Play Store version of the F-Droid-hosted apps.
rollcat 3y ago
> Putting up all sorts of requirements on where and how to build is not helpful [...] Well that's the general trajectory of what I'm thinking about - NOT hurdles, but infrastructure AND incentives for developers, that will help their products grow, OSS or not. What if Flathub helped you publish native Linux builds on Steam? > Most upstream developers will likely have their own infrastructure. Bingo. Right now to cover the three major platforms on self-hosted infra, you need to at least 1. buy a Mac, which no longer has an x86-64 CPU, so no dual/triple booting and the VM story isn't exactly here yet, 2. therefore also buy a PC, which you probably want to dual-boot if you're cost-conscious, which means you will probably have either only one native Windows OR Linux builder online at a time, OR make it a VM host which will require more hardware resources and perhaps limit its portability (so you're more likely to buy a more expensive Macbook and make that your portable workstation, rather than a cheaper Mac mini), or 3. buy an extra PC to host the "other" builder. It's 100% reasonable to go for a hosted CI solution; I'm not saying "let's copy whatever Apple does", but they do offer Xcode Cloud, so that developers can benefit from vertical integration. All platforms benefit from integration, whether it's more horizontal, vertical, or both boils down to strategy, and I think it would be beneficial to explore more angles.
- jillesvangurp 3y ago
  Sure, as long as it's optional. I wasn't necessarily referring to self hosting your own infrastructure but simply to the notion that for most applications out there, building them is kind of a solved problem already and flatpak likely isn't the center of their universe but more like one of several things they need to support. Offering some build infrastructure is nice but sounds like it would just end up competing with what is out there already. Unless you have a particularly novel/good take on that, you are basically just putting a lot of effort into cloning stuff that you can already get elsewhere for reasonable fee. Making the use of that mandatory vs. use your own and upload the binary is what the article is about. I think not supporting uploads is not really going to be a thing based on the discussion here. I can't judge the wisdom of adding some optional build infrastructure. Maybe this all just boils down to some people needing an excuse to start doing this because they are interested in building such a thing. I'm not against that of course. Go for it. But it sounds like it would involve quite a bit of cost and infrastructure that isn't necessarily core to what flathub is about.

vetinari 3y ago

> Most upstream developers will likely have their own infrastructure. So, the added value is dubious. They could make it optional; but the artefacts of those who use it, would be more trustworthy, since flathub can guarantee their BOM. The same way, as you can trust binaries from F-Droid more, than from Google Play.

gjsman-1000 3y ago
> The same way, as you can trust binaries from F-Droid more, than from Google Play. Actually, no. I'm forgetting the exact details - but F-Droid (if I recall correctly) re-signs all packages with its own key, removing the developer's signing key. There's some infrastructure reason for it. Google Play keeps that key. This is also why GrapheneOS offers sandboxed Google Play and recommends using that over F-Droid. https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/
- mook 3y ago
  F-Droid will use your original signatures as long as they can rebuild the binary to be identical (excluding the signature), to verify that everything is open source. They only discard your signatures if they can't confirm that, to avoid issues with hosting proprietary bits. https://f-droid.org/docs/Reproducible_Builds/ https://f-droid.org/docs/Reproducible_Builds/
- seba_dos1 3y ago
  > but F-Droid (if I recall correctly) re-signs all packages with its own key, removing the developer's signing key The reason why they do that (in some cases) is exactly why F-Droid is more trustworthy than Google Play.
- piaste 3y ago
  I run GrapheneOS. It's an amazing project, and I always pay attention to what their developers say. But you should keep in mind that the GrapheneOS project is very laser-focused on a certain threat model: aggressively malicious software that tries to exploit vulnerabilities to escape its sandboxes. And they fight against that threat very well (there have been a couple of recent high-profile Android CVEs to which GrapheneOS users were immune). But they are - rightfully - less concerned about the far more common threat of apps including crapload of tracking libraries, battery-burning ads, or dark patterns requesting unnecessary permissions. They provide you with tools to fight them - Storage Scopes and Contact Scopes are amazing! - but ultimately it's up to the user to e.g. choose a serious calculator app like Calculator++ instead of some spyware. And against that threat, it is an excellent idea to search on F-Droid first instead of the Play Store (where the first non-Google, non-Samsung result is indeed an ad-filled spyware calculator). Then, if you want to secure yourself against the possibility of the F-Droid signing keys being compromised, you may choose to delay/disable automatic updates, or simply to download the Play Store version of the F-Droid-hosted apps.

rollcat 3y ago

> Putting up all sorts of requirements on where and how to build is not helpful [...] Well that's the general trajectory of what I'm thinking about - NOT hurdles, but infrastructure AND incentives for developers, that will help their products grow, OSS or not. What if Flathub helped you publish native Linux builds on Steam? > Most upstream developers will likely have their own infrastructure. Bingo. Right now to cover the three major platforms on self-hosted infra, you need to at least 1. buy a Mac, which no longer has an x86-64 CPU, so no dual/triple booting and the VM story isn't exactly here yet, 2. therefore also buy a PC, which you probably want to dual-boot if you're cost-conscious, which means you will probably have either only one native Windows OR Linux builder online at a time, OR make it a VM host which will require more hardware resources and perhaps limit its portability (so you're more likely to buy a more expensive Macbook and make that your portable workstation, rather than a cheaper Mac mini), or 3. buy an extra PC to host the "other" builder. It's 100% reasonable to go for a hosted CI solution; I'm not saying "let's copy whatever Apple does", but they do offer Xcode Cloud, so that developers can benefit from vertical integration. All platforms benefit from integration, whether it's more horizontal, vertical, or both boils down to strategy, and I think it would be beneficial to explore more angles.

jillesvangurp 3y ago
Sure, as long as it's optional. I wasn't necessarily referring to self hosting your own infrastructure but simply to the notion that for most applications out there, building them is kind of a solved problem already and flatpak likely isn't the center of their universe but more like one of several things they need to support. Offering some build infrastructure is nice but sounds like it would just end up competing with what is out there already. Unless you have a particularly novel/good take on that, you are basically just putting a lot of effort into cloning stuff that you can already get elsewhere for reasonable fee. Making the use of that mandatory vs. use your own and upload the binary is what the article is about. I think not supporting uploads is not really going to be a thing based on the discussion here. I can't judge the wisdom of adding some optional build infrastructure. Maybe this all just boils down to some people needing an excuse to start doing this because they are interested in building such a thing. I'm not against that of course. Go for it. But it sounds like it would involve quite a bit of cost and infrastructure that isn't necessarily core to what flathub is about.