Please review the draft for May's report

[Leo Wandersleb]

The client side automation/protection is a huge headache for the project I think.

https://WalletScrutiny.com aims to protect as many users of wallets as possible
and therefore does not look at the license but only at the fact if there is
public source code or not. I have little hope that a significant percentage will
switch to FDroid for extra security if FDroid would increase the protection
regarding reproducibility. To my understanding, reproducibility is something
nice to have on FDroid but not something I can require as an app provider or app
user.

Instead I hope to get solid enough red-flag-situations to convince Google to
stop rollout of flagged releases or to get wallet developers to integrate a
kill-switch mechanism for red-flag events. The kill-switch mechanism will at
first be a stand-alone app that probably switches off internet and notifies the
user to only activate internet again after deactivating auto-updates of the
affected wallet. Something like that.

(Red-flag events would be back doors or severe bugs discovered in the code but
also non-reproducible builds found in the wild or reproducible builds found that
were rushed.)

I just started trying to get independent rebuilders on board, in the form of
competing wallets. Being a sole rebuilder is really shaky grounds.

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?

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.

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200609/91897de9/attachment.sig>