3 ms·

I'm the opposite of you. I want the code to be rigid and deterministic. I want fdroid to be reliably exactly what is on GitHub. If you want anarchy, you can a

• lucideer 5y ago
  I'd love to be the same as you, but I've been an F-Droid user for many years, and I still reluctantly but heavily rely on Aurora[0] because of the dearth of good options on F-Droid. I don't mean to shit on the efforts of FOSS maintainers, many of the apps are amazing, but F-Droid is packed full of abandonware, and I can't help but thinking that creating more barriers to entry doesn't help those maintainers. These strict approaches to vetting software we use are lovely in theory, but in practice the open-source community is criminally under-resourced, and applying further self-taxation on top of that isn't really ideal. This isn't to say we need to compromise on security: you can have checks in place ensuring source is accessible for listing approval, and if you have infra available you can run static analysis and software-composition analysis on said source. Neither of those automation steps involve significant barriers for maintainers to submit (the only potential barrier is in acquiring approval for very insecure software if checks fail), and both would improve security significantly above and beyond the current custom build requirements. You can argue the resources required for SA / SCA may be greater than those required for custom build, but if that's the case then you're evidently not doing custom builds for security reasons, so the argument is moot. [0] https://f-droid.org/en/packages/com.aurora.store/ https://f-droid.org/en/packages/com.aurora.store/