hmmm. mediated access. how do I know to trust the hash checksum checks? Feels like it requires an independent tool to verify what I should get and what I do get because .. trust isn't transitive through a proxy.
Yea I can see how you could know. The problem is.. a tool like this has the awesome and can say "oh yes I checked all those this random APK is definitely the one you wanted"
Thats what F-Droid and Google store (and the apple store) do: they stand their assets as "if we lied, you know where to find us" regarding the provenance of what they pass. They do of course, also routinely (ok not Apple mostly) pass apps which do heinous bad things, because it turns out there's only so much automated tests can find.
As you observe, sometimes the promise is hollow. (F-Droid)
We depend upon package repositories to maintain the list of packages for a given namespace, and to always serve the most recent signed list of packages for the requested, some, or all namespaces in the repository's package catalog. The SLSA and TUF specs summarize the vulnerabilities, risks, and components of software supply chain security.
> There is a big emphasis on operating in the public and making everything publicly available. We include source tarballs and build logs when we publish binaries
What's a ballpark figure for what the monthly cost to Fdroid would be to scan all uploaded APKs for security vulnerabilities?
Practically, it should be easy to add an upload_scan_and_post_back_to_the_pull_request task to each project's e.g. GitHub Actions YAML build definition; but then how does or how can SLSA help prove that the scan results were actually requested and merging and releasing were prevented if positive?
