Project

General

Profile

Feature #12630

Feature #5630: Reproducible builds

Document how users can verify a reproducibly built ISO/IUK

Added by u 4 months ago. Updated 4 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
06/02/2017
Due date:
% Done:

100%

QA Check:
Feature Branch:
feature/12630+reproducible_build_verify
Type of work:
Contributors documentation
Blueprint:
Easy:
Affected tool:

Related issues

Related to Tails - Feature #12626: Report back to the reproducible builds community about how we did it Confirmed 05/31/2017
Related to Tails - Bug #12645: FAQ: Explain why we don't give a SHA of the ISO image Confirmed 06/06/2017
Related to Tails - Feature #14520: Prepare & publish a blog post about testing Tails ISO reproducibility Resolved 08/30/2017

Associated revisions

Revision 60764371 (diff)
Added by intrigeri 9 days ago

Remove the "quick" ISO build instructions (refs: #12630).

Let's improve our existing build instructions instead of endeavoring ourselves
to maintain 2 set of instructions.

History

#1 Updated by u 4 months ago

  • Assignee set to u

Notes

- download our .sig and verify it against your own build
- when someone reproducibly builds our .iso they have a file that is exactly the same as ours, which the .sig will verify for them
- there's a way to extract the SHA from the .sig.
- the SHAAA is already in IDFs and UDFs

#2 Updated by intrigeri 4 months ago

- download our .sig and verify it against your own build

This won't work for IUKs though, but their SHA is available in our UDFs.

#3 Updated by u 3 months ago

  • Feature Branch set to 451f:tailsfeature/12630+reproducible_build_verify

#4 Updated by u 3 months ago

  • Status changed from Confirmed to In Progress

#5 Updated by u 3 months ago

  • Assignee changed from u to intrigeri
  • QA Check set to Ready for QA

I added a page about this and would love someone from the foundations team to verify what I wrote and improve on it. Tentatively assigning to intrigeri.

  • I don't know how to verify an IUK so this part is missing
  • Is there an archive of our OpenPGP signatures so that people can verify older builds in the future?
  • Is there an archive of our IDFs/SHAsums so that people can verify older builds in the future?

You can also reassign this to me if you think there is too much information missing.

#6 Updated by u 3 months ago

  • Related to Feature #12626: Report back to the reproducible builds community about how we did it added

#7 Updated by u 3 months ago

  • Assignee changed from intrigeri to anonym

Actually, as anonym is supposed to write the design doc, this might be more suitable to have a review from him instead.

#8 Updated by intrigeri 3 months ago

  • Target version set to Tails_3.1
  • % Done changed from 0 to 10

#9 Updated by intrigeri 3 months ago

  • Is there an archive of our OpenPGP signatures so that people can verify older builds in the future?
  • Is there an archive of our IDFs/SHAsums so that people can verify older builds in the future?

There's no such archive but enabling people to verify old releases is not part of our goals IIRC. I think we've set up things so that only the last release (and perhaps the one before if you're lucky) can be verified. The blueprint might have clearer statements about this.

#10 Updated by u 3 months ago

  • Related to Bug #12645: FAQ: Explain why we don't give a SHA of the ISO image added

#11 Updated by anonym 3 months ago

  • Target version changed from Tails_3.1 to Tails_3.2

#12 Updated by anonym about 1 month ago

  • Assignee changed from anonym to u
  • % Done changed from 10 to 60
  • Feature Branch changed from 451f:tailsfeature/12630+reproducible_build_verify to feature/12630+reproducible_build_verify

Looks great, no comments from me!

I completed the IUK section, and I opted to automate the process of getting the right checksum. It's a bit hairy (shell code generating Python code, here-document vs Python's strict indentation, ...) but since this code is targeting contributors I think it's fine. :)

#13 Updated by bertagaz about 1 month ago

intrigeri wrote:

  • Is there an archive of our OpenPGP signatures so that people can verify older builds in the future?
  • Is there an archive of our IDFs/SHAsums so that people can verify older builds in the future?

There's no such archive [...]

Hmm, that's in our Git history at least, right? (well, with "only" signatures of the UDF)

anonym wrote:

It's a bit hairy (shell code generating Python code, here-document vs Python's strict indentation, ...)

oO !

Heading reading this!

#14 Updated by u 23 days ago

Add / Verify technical part from first email we sent out to ask users for help: https://mailman.boum.org/pipermail/tails-dev/2017-August/011591.html

#15 Updated by u 23 days ago

  • Related to Feature #14520: Prepare & publish a blog post about testing Tails ISO reproducibility added

#16 Updated by u 9 days ago

  • Assignee changed from u to intrigeri

I've remodified the documentation a little bit and added a "quick" build instructions file in order to make it easier for most people. I think this will very likely raise intrigeri's interest and that's why I'd like him to do a final review. What do you think intrigeri?

#17 Updated by intrigeri 9 days ago

  • Assignee changed from intrigeri to u
  • % Done changed from 60 to 70
  • QA Check changed from Ready for QA to Dev Needed

Thanks for pointing this to me! Indeed, I'm interested and as you might guess I have strong opinions on this matter ;)

I dislike the introduction of contribute/build/quick but I'm very happy you did it: it forces me/us to look at a rather ugly corner of our website and to think about how it should be :)

I dislike adding this new page for 2 main reasons (I also have concerns about its content but that's pointless since I simply would like that page not to exist):

  • We already have a hard time keeping contribute/build up-to-date and usable (e.g. #11411), and I'm convinced that having two pages to maintain (and keep in sync') instead of one will make that worse both for us and for anyone who follows one of these two pages.
  • This new page fixes bugs that still exist on contribute/build, e.g. the missing git submodule update --init. Not only this incidentally proves the previous point by showing how hard it is to keep these two set of instructions in sync, but perhaps more importantly, it shows that having 2 sets of instructions can make is point most contributors to a known-buggy doc page while the bugs are fixed in a new page (that's itself used in corner cases only).

Now, I'm not adverse to change in this area, quite the opposite. I think I understand what prompted you to create this new page: when editing the call for reproducibility testing blog post, instructions that came from contribute/build stroke me as not good enough to publish on Planet Debian even as a guest post (e.g. information presented in less than ideal order, uselessly forcing the reader to choose between various options), so I ended up rewriting lots of it… without contributing my improvements back to contribute/build, and without even filing a ticket about it — bad intri, bad! I could almost feel ashamed but that's not my style.

Thanks to this past experience + your branch proposal, I think I now have a clear vision of the changes I would like to see happen on contribute/build, and I'm actually excited to make it happen soon. So I propose you rollback the addition of contribute/build/quick, point to contribute/build instead, and I file a blocking ticket assigned to me about improving contribute/build and making it good enough to avoid the need for a "quick" version. I don't know when exactly we want to publish the documentation this very ticket is about, but I'm flexible and confident I can get these improvements ready within a timeframe that'll suit you. I would love if you could be the reviewer for these changes, and if you have the bandwidth, I could outline my plan so we can discuss it before I implement it (could be nice, or too much overhead, I dunno, your call).

What do you think?

I hope you did not spend too much time on this new page… but even if you did, it has already been useful and will be useful again if you agree and I rework contribute/build!

#18 Updated by u 9 days ago

  • Assignee changed from u to intrigeri
  • QA Check changed from Dev Needed to Info Needed

intrigeri:

I totally understand your reasoning and I knew when I created quick.mdwn that you would tell me exactly this: "hard time to maintain build.mdwn already". I did it nevertheless, because when I read build.mdwn I get the feeling that I want to stop even trying to build a Tails ISO image after 5 sentences ;).
So, no, I don't mind if you rework this.

However, I am a bit surprised that no sentence in your gigantic comment talks about build/reproducible.mdwn - which is the page this ticket is really about.
So before I rollback anything, I'd like to have an opinion on this part.

And yes, I can review what you will comme up with. And we can chat about it beforehand.

#19 Updated by u 9 days ago

  • QA Check changed from Info Needed to Dev Needed

We agreed that intrigeri will also review reproducible.mdwn and rework the build instructions in time for 3.2 but after the freeze.

And he can rollback the revisions corresponding to quick.mdwn himself.

Please reassign to me for review.

#20 Updated by intrigeri 9 days ago

We agreed that intrigeri will also review reproducible.mdwn

Not done yet.

and rework the build instructions

Done, pushed to the topic branch.

And he can rollback the revisions corresponding to quick.mdwn himself.

Done.

Please reassign to me for review.

You can start reviewing the new contribute/build whenever you want (129 insertions(+), 293 deletions(-) :)

#21 Updated by intrigeri 9 days ago

  • QA Check changed from Dev Needed to Ready for QA

#22 Updated by intrigeri 9 days ago

  • Assignee changed from intrigeri to u

I've reviewed contribute/build/reproducible and modified it quite a bit (surprise!). I've tried to justify my changes in the commit messages, in the hope that if you disagree we can have a nicer and more productive discussion :)

Another change I almost did was to move "Why is it important?" immediately after "What are reproducible builds?": together they explain what's the whole point of the exercise. Given we point directly to the "How do I verify […]" section from contribute/build, most readers of the page won't see the meta-blah, which was your goal, right? If you agree it would be better structured this way, feel free to do it and merge directly.

#23 Updated by u 4 days ago

  • QA Check changed from Ready for QA to Pass

wohoo! I will merge this. Yeah, I had put "Why is it important" lower. But as we point to it with an anchor it's fine. I'll move it upwards. Thanks for this gigantic improvement!

#24 Updated by u 4 days ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (u)
  • % Done changed from 70 to 100
  • QA Check deleted (Pass)

Merged!

Also available in: Atom PDF