> > https://walletscrutiny.com/ was mentioned, though. > > IMHO an interesting and worthwhile project. It probably could use more > > automation in verifying reproducibility. > > > > How would the app-update workflow work in a perfect world, where we do > > not have to trust the app builder? > > > > Maybe like this: > > 1. developer pushes a signed git tag to the official repo > > > > 2. multiple independent builders build binaries and sign some > > "buildinfo" about source+binary hashes, publish it to some > > buildinfo-collection place. > > > > 3. after N trusted rebuilders agreed on what the correct binary should > > be, the app-store (e.g. F-Droid) publishes the binary for all users > > > > 3b. in theory, this could use anonymous uploads, where anyone can > > upload a binary to server.domain.tld/public/HASH as long as the HASH > > of the upload is the correct one. > > > > 4. F-Droid client pulls new app version and signed buildinfo files and > > checks if F-Droid server did the right thing > > I did not understand what the anonymous uploads would be good for. If the > uploader is anonymous, what signal does his action send? If the hash is known, > what good is it to upload the file? >
Bernhard's point is that if Alice has a PGP trust path to a hash value [e.g., if Bob signed some hash value and Alice trusts Bob's key], has a file whose hash is that value, and the hash function is sufficiently strong, then Alice may trust that file as well, _regardless of its origin_. That's just the standard property of signatures. If you're on a plane and someone hands you a signed message that verifies to be from a trusted key, then you can trust the message is from that key's owner even if you don't trust whoever handed you the message. > If FDroid would allow the user to pick trusted rebuilders as a prerequisite > for > any update, that would definitely improve the security, especially if the > FDroid > client enforced it. Cheers, Daniel