Please review the draft for May's report

[Daniel Shahaf]

> > 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