Tails

#1 Updated by Anonymous 2017-06-02 12:50:30

• Assignee deleted (None)

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

#3 Updated by Anonymous 2017-06-21 18:34:47

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

#4 Updated by Anonymous 2017-06-21 18:34:56

• Status changed from Confirmed to In Progress

#5 Updated by Anonymous 2017-06-21 19:15:28

• Assignee set 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 Anonymous 2017-06-21 19:16:23

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

#7 Updated by Anonymous 2017-06-21 19:16:53

• 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 2017-06-22 13:53:52

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

#10 Updated by Anonymous 2017-06-27 08:20:43

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

#11 Updated by anonym 2017-07-06 14:15:03

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

#12 Updated by anonym 2017-08-14 18:10:31

• Assignee deleted (anonym)
• % 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. :)

#15 Updated by Anonymous 2017-08-30 09:47:06

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

#16 Updated by Anonymous 2017-09-12 16:30:28

• Assignee set 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 2017-09-13 07:57:20

• Assignee deleted (intrigeri)
• % 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. Bug #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 Anonymous 2017-09-13 09:19:25

• Assignee set 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 Anonymous 2017-09-13 09:39:11

• 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.

#21 Updated by intrigeri 2017-09-13 11:42:29

• QA Check changed from Dev Needed to Ready for QA

#22 Updated by intrigeri 2017-09-13 12:30:50

• Assignee deleted (intrigeri)

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 Anonymous 2017-09-18 10:24:14

• 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 Anonymous 2017-09-18 10:26:53

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

Merged!