> Using automation to automatically update packages is mostly a good thing.
Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?
The enormous amount of value the distros bring (aside from sponsorship of the ecosystem) is audit of packages (and packaging). If we want to move application packaging away from the distros, Flathub needs to be at least as competent in its process, automated or not.
> The enormous amount of value the distros bring [...] is audit of packages (and packaging).
Yes, auditing against supply chain attacks is good! But there's also a risk in running outdated software. I don't have easy answers. But if automation leaves more time for the hard part, great.
Maybe unfair to ask you (but thanks for the helpful answers so far).
Is there a check for "this distribution comes from the official source"?
Let's say some state actor compromises taaem's desktop computer, and changes the url in the manifest to (say) https://xn--githb-bjg.com/bitwarden/clients/releases/downloa... (that's a unicode lookalike ս in there, which in github at least renders without expansion as "github.com" - HN is smart enough to expand it), or something equally nefarious. CI's not going to catch that, right? And nobody's actually paying attention to changes?
Not an expert, but unfortunately I think you're right in identifying a potential attack vector with the Flathub maintainership model. Even if flathubbot is being used, manual changes can still be made by maintainers.
And I think there are far more maintainers to trust, than for say scoop or winget. The difference is, Flathub has one repo per package (and hence allows more maintainers).
Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?
The enormous amount of value the distros bring (aside from sponsorship of the ecosystem) is audit of packages (and packaging). If we want to move application packaging away from the distros, Flathub needs to be at least as competent in its process, automated or not.