Commit 412b64f4 authored by anonym's avatar anonym
Browse files

Encode our requirements on reproducibility in the release process.

Will-fix: #12629
parent cdf3c503
......@@ -562,6 +562,10 @@ suite should be ready, so it is time to:
* build the final image!
* make sure at least two `tails@` members will build the ISO
image. Example: if you, the RM, is a `tails@` member, you only have
to ask one more member.
* compare the new build manifest with the one from the previous,
almost final build; they should be identical, except that the
`debian-security` serial might be higher. To ensure we publish
......@@ -660,6 +664,9 @@ Note that developer tools for creating IUK and upgrade-description
files were only tested on Debian sid. It should hopefully work well on
Jessie too.
Make sure at least two `tails@` members reproduce the same IUKs.
Provide them with the value of `IUK_SOURCE_VERSIONS` that you used!
<a id="prepare-upgrade-description-files"></a>
Prepare upgrade-description files
......@@ -816,6 +823,72 @@ Sanity check
Verify once more that the Tor Browser we ship is still the most recent (see
above).
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!
* If everyone reports the same hashes: 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
undo everything done from this point on. It's still a good idea to
optimistically assume success in order to not be blocked at this
point. However, be mentally prepared that it might have to be done
once more, and make sure to return to this section once everyone is
done with their reproduction attempts, and certainly before making
the release public.
* If there is a hash mismatch for the ISO: ouch! Now we are in a
tricky situation: on the one hand it seems like a poor idea to block
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! :)
- 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!
- Otherwise:
* If the source of non-determinism is identified quickly and is
easy and fast to fix, *and* the QA of the current ISO has not
gone very far (so at least that time is not wasted), then you
should consider abandoning the current version, and immediately
start preparing an emergency release with:
- the reproducibility fix
- a new changelog entry,
- adjustments to the release notes so they are re-purposed for
this emergency release (the abandoned release gets none, since
it effectively never will be released publicly).
* Otherwise, let's release any way. But let's add a known issue
about "This Tails release has reproducibility issues" to the
release notes, linking to the ticket(s) (or similar) where the
nature of the reproducibility failure is clearly described.
* If there is a hash mismatch for an IUK (or several): proceed with
the release, except for the problematic IUK(s); remove them from the
mirrors, and remove the affected incremental upgrade paths from the
UDFs! In parallel with the rest of the release process, try to
figure out what the problem with the IUK is and fix the cause, so a
good IUK can be released as soon as possible. If a seemingly
malicious difference is found, then immediately halt the release and
go to the "If something seemingly malicious is found" case for the
ISO above. Because of this it is advisable to not publicly release
until malicious differences have been ruled out.
<a id="publish-iuk"></a>
Publish the ISO and IUK over HTTP
......
......@@ -10,7 +10,11 @@
- Send the release schedule to <tails-dev@boum.org> and
<tails-l10n@boum.org>.
Ask the core team and contributors for availability at the
dates designated for testing the RC and final image.
designated dates:
* for testing the RC and final image.
* for reproducing the ISOs and IUKs for the RC and final release.
Note that at least 2 `tails@` members are required to participate
(one of them could still be the RM)!
- Update [[contribute/calendar]] accordingly.
- Update the due date on [[!tails_roadmap]] accordingly.
- Ask to be added to the `rsync_tails` group on `rsync.lizard`,
......
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