Commit 7479d707 authored by anonym's avatar anonym
Browse files

Let's be real and don't try to protect against "rouge RMs".

For example: at the moment a rouge RM could upload a compromised .deb
to our custom APT repo without our process being able to identify it,
so let's not even pretend that we are working towards "rouge RM
resistance" just yet.

Refs: #12629
parent 412b64f4
......@@ -827,12 +827,10 @@ Reproducibility
Previously you have asked `tails@` members to reproduce the Tails ISO
image and all IUKs. Now tell all these members to exchange the
`SHA-512` hashes of their ISO and IUKs with each other over encrypted
and signed email; everyone must independently pay attention that the
emails are signed!
image and all IUKs; now tell all participants to send you the
`SHA-512` hashes of their ISO and IUKs over signed email.
* If everyone reports the same hashes: yay, we're good to go!
* If all hashes match: yay, we're good to go!
* If the reproduction attempts haven't been completed yet: continue at
your own risk! If you get a negative answer later you might have to
......@@ -848,14 +846,14 @@ emails are signed!
users from benefiting from this release's security updates, but on
the other hand the failure might imply that something nefarious is
going on. At this stage, no matter what, immediately compare the
ISOs (using `diffoscope`) and try to rule out that the RM has gone
rouge by including a backdoor! :)
ISOs (using `diffoscope`) and try to rule out build system
- If something seemingly malicious is found, then let's take a step
back: we might be compromised, so we are in no position to
release. Halt the release, involve the rest of `tails@`, and then
try to re-establish trust between all participants, in all
machines and infra involved, etc. Have fun!
try to re-establish trust in all build machines and infra
involved, etc. Have fun!
- Otherwise:
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment