Assumptions:

* RM is not evil ♥
* a compromised RM system can block arbitrary outgoing communication (e.g. email) so it cannot be trusted to initiate a check that's precisely meant to verify whether said system is compromised (and compromising our published products)
* RMs don't plug their smartcard in a computer outside of the release process (XXX: need a policy or "common sense" (sic) applies?)
* Our web site and the webserver that runs is is trusted (so much of other Tails stuff relies on this that we can't reasonably set the bar higher).
* An attacker publishing a compromised Tails needs to update the IDF, UDFs and/or detached signatures to our website, and possibly replace a Git tag. If this is done through Git, there's a much greater chance we notice it outside of our release process than during it. (If this is done directly on the web server, chances are that we don't notice it and it could even survive Git push and web site refresh, but it's out of scope here as said above.)

Goals:

1. identify reproducibility bugs (ideally before releasing)

   * We are claiming that we release reproducible products. We don't want to lie to the world.
   * We will hopefully involve third-parties in the reproducibility verification process at some point; they'll need confidence that our products are reliably reproducible, otherwise they might be discouraged and stop even trying.
   * A reproducibility bug can be a symptom of another bug.

2. identify compromised RM system ASAP and consequently compromised Tails product

   * Allow RMs to sleep better at night.
   * Avoid letting users use a compromised Tails.

3. be as cheap and non-stressful as possible for everyone involved

   Generally, anything that has to be done in a tight timeframe is stressful.
   Specifically, steps that block the release process are stressful because it's hard to predict when one will need to be available to go through them.

4. *try* to make the process not depend on both anonym and intrigeri in a tight, not well defined timeframe (e.g. during release process) :)

5. XXX: ensure what we've tested (QA) and reproduced matches what is published

Solutions:

* Do the first reproducibility check via Jenkins only, to identify bugs. This is about goal 1 and not goal 2. Let's add this to the "manual" testing section.

* Do the last reproducibility check after the RM has unplugged their smartcard => the attacker must have had the compromised RM system sign arbitrary data earlier, and then either publish the compromised product during the confused release process time (when there's less chance for it to be noticed) or later (and then they have a good chance to be caught). This raises the bar for a successful attack a bit (goal 2).

pros: detect attack done during the release process; cons: window during which users can download a compromised Tails

inputs: commit of the tag at the time of the QA tests, hash of the products that were tested
sent by testers to the TR
ASAP after the release is out and the RM has unplugged their smartcard, the TR:
fetches from Git
downloads products
verifies the current tag matches the aforementioned commit
builds products
verifies built product match what was tested and what's online (on download servers and in IDFs + UDFs)

XXX: automate this

the rest of the time: when merging origin/master, be careful about what's going on in the UDFs, IDFs, detached signatures and Git tags. until we have monitoring of these things and alerts whenever they change.

XXX: who? when? trigger?

who = tails@ (MUST) and in practice probably another RM; proposal: anonym and bertagaz, depending on who's the RM; intrigeri can also be tasked with it _when scheduling the RM and TR shifts_ if the other people cannot.

ideally the day after the release; worst case within 72h

encode who's the TR in [[contribute/calendar]] when scheduling RM shifts

pay this 1h/published ISO out of the manual testing budget => propose on summit@