Tails

#1 Updated by Anonymous 2017-03-17 10:52:06

• related to Feature #12355: Communicate about RB efforts to RB community added

#2 Updated by Anonymous 2017-06-27 09:09:51

• Status changed from New to Confirmed
• Target version set to Tails_3.2
• Starter set to No
• Deliverable for set to 289

#3 Updated by Anonymous 2017-09-05 19:42:22

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

This shall happen right after 3.2

#4 Updated by intrigeri 2017-10-02 12:38:03

• Deliverable for changed from 289 to 301

#5 Updated by intrigeri 2017-10-02 12:38:28

• blocked by Bug #12629: Document reproducible release process added

#6 Updated by Anonymous 2017-10-04 18:12:07

• Feature Branch set to 451f:tails/feature/12356+reproducible_blog_post

I’d like to publish this either right before 3.3, or when 3.3 is out. This blog post is also part of the donation campaign.

I’d be happy if anybody could proofread this and i’m also in for comments!

#7 Updated by Anonymous 2017-10-04 18:12:28

• Status changed from Confirmed to In Progress

#8 Updated by Anonymous 2017-10-04 18:15:10

• Assignee set to anonym
• QA Check set to Ready for QA

Care to proofread this anonym?

When done please reassign to intrigeri who can reassign to me.

Thanks <333

#9 Updated by Anonymous 2017-10-11 13:27:21

• related to Bug #14831: Write blogposts for the donation campaign added

#10 Updated by anonym 2017-10-13 12:03:24

• Assignee deleted (anonym)
• % Done changed from 0 to 60
• QA Check changed from Ready for QA to Dev Needed

Here’s my review:

> with the release of Tails 3.3 you will hold in your hands

Nitpicking: I’m not sure how to hold an ISO image (i.e. data) in my hands. :) I don’t really care about this one, but to me it seems we might as well do s/you will hold in your hands/we are proud to present you/ or something.

> the world’s first
> reproducibly built ISO image (that we know of at least!).

We’re not first: http://webconverger.org/blog/2016/Webconverger_has_reproducible_builds/

So s/the world's first/one of the world's first/. And I think “ISO image” is not enough (with xorriso this is trivial), and I would prefer s/ISO image/Linux-based operating system/ or something similar.

> Or could an evil waiter have added

In this analogy, the waiter is to me analogous to the transfer of the already built ISO image (so it would fit better when describing the need for ISO verification). I think it would be more accurate to talk about unauthorized personnel breaking into the kitchen at night, and then poisoning the ingredients and making the oven cook at 50C higher than displayed. :)

I’m wondering if the analogy would get stronger if the different roles got explained better, e.g.

• “chefs and aides in the kitchen” "Tails developers and contributors" * "evil waiter" “evil mirror or ISP intercepting the transfer”
• “evil chef in the kitchen” "compromised Tails developer" * "evil agent compromising the oven in the kitchen at night" “NSA compromising our build systems and infrastructure”

That might help readers to distinguish between the two different kinds of verification we talk about. But I guess it would require working on this text quite a bit more, and it is already so good that I don’t think this is needed. OTOH, it’d be great if we later extract this analogy to e.g. https://tails.boum.org/doc/about/trust/.

What do you think?

> poison or modify an important ingredient?

s/modify/modified/

> This makes it now possible to compare ISO images built by multiple
> parties from the same source code and to ensure that they all result in exactly
> the same ISO image.

I feel this report doesn’t really make it explicit why this works, e.g. it lacks some argument about that it is extremely unlikely for multiple independent parties to be compromised in the exact same way that the Tails project would be, in case we were/are/will be. (And maybe also that our adversaries cannot know in advance who will attempt to do this, and they probably cannot compromise all the millions of systems that potentially will be used to reproduce Tails at some point.)

> With reproducible Tails, any independent party could build
> their own ISO image from our source code and verify that it is the same one
> that we distribute.

I think this would be more powerful if phrased about what it prevents, e.g.: “With reproducible Tails, it only takes one knowledgeable person to build Tails and compare with the ISO image the Tails project distributes to uncover a backdoor.” IMHO there’s a similar argument to be made as in the “Free software and public scrutiny” section of Trusting Tails that it doesn’t require everyone to do this verification, which would be impossible since not everyone has the needed skills.

> Your giving us a hand is much

I think s/Your/You/, although IIRC some Americans use that manner of speaking.

> you to read our [report to the Reproducible Builds
> community|/blueprint/reproducible_builds/report_to_RB_community] about how we
> did it.
>
> We’ve also published technical [instructions to
> verify|/contribute/build/reproducible/#verify-iso] one’s own
> [build|/contribute/build/].

You use single brackets, but all these ikiwiki directives must use double brackets.

> Care to give us a hand to make Tails bake even better cakes in the
> future?

I love this! :)

I also ran the whole text by a person that doesn’t really know what all this is about, and they gave it “9.5 dolphins [out of 10?] in understandability”, so:

Well done! \o/

#11 Updated by Anonymous 2017-10-13 15:11:57

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

#14 Updated by Anonymous 2017-10-13 15:36:56

• Assignee set to intrigeri
• QA Check changed from Dev Needed to Ready for QA

Hello intrigeri,

you might want to have a look at that too.

Let’s not merge it before Tails 3.3 is out though.

#15 Updated by Anonymous 2017-10-13 15:37:33

• related to Feature #12035: Donation campaign 2017 added

#16 Updated by Anonymous 2017-10-13 15:38:01

• Subject changed from Communicate about RB effort to users to Communicate about reproducible builds to users via a blog post

#18 Updated by intrigeri 2017-10-16 05:57:30

• Assignee deleted (intrigeri)
• QA Check changed from Ready for QA to Dev Needed

Wow, excellent! This was a very pleasant read :)

• The top-level headings should be h1 (===) for consistency with the rest of our website (yes, I know we have a HTML semantics bug there but let’s be consistent and if we want to fix it, let’s fix it everywhere).
• I’m not sure about “reproducibly built”: it sounds like it puts under the spotlights the fact that we’ve successfully reproduced the ISO build ourselves; how about “reproducible” instead, to put the focus on the fact anyone can reproduce it?
• s/PGP/OpenPGP/
• “Download And Verify Extension” (and any other software name) should be in italics (see our doc style guide that probably has a better explanation)
• In a few places you capitalize a word after “:”. Fine by me if that’s a style effect.
• “could even one of the chefs have been compromised and unknowingly use a vegetable which will make all of us sick and at least get a stomach ache? That’s what reproducible builds help verify and protect against” is incorrect I think: in the current state of thing (see Bug #12629) we trust at least the RM and their machine/system. Same for “gain confidence that no evil cook or broken oven”.
• I would use quotation style (prefix lines with > ) instead of preformatted code block for the quote.
• s/several months/a year/ maybe?
• “to uncover a backdoor” (somewhat) suggests this verification works for any backdoor, which is incorrect. I don’t know if it’s worth complicating the phrasing to make it more correct (e.g. “to uncover some kinds of backdoors”). Your call!
• In the “Thank you” paragraph I would like us to also thank the Reproducible Builds community that provided critical help in at least 2 places where we strongly needed it.

#19 Updated by Anonymous 2017-10-16 11:49:56

• QA Check changed from Dev Needed to Info Needed

Thanks for the second review, intrigeri! Much appreciated.

I’ve implemented all your remarks except:

Concerning your comment about Bug #12629, do we agree that we will have a or several reproducers? This is something you proposed on the ticket and that I at least silently agree with. I’m unsure if we need to explain this in detail to our users. What’s your take on this?

#20 Updated by Anonymous 2017-10-16 12:16:47

• Assignee set to intrigeri

#22 Updated by intrigeri 2017-10-16 12:32:06

• Assignee deleted (intrigeri)
• QA Check changed from Info Needed to Dev Needed

#23 Updated by Anonymous 2017-10-16 13:13:45

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

intrigeri wrote:
> > Concerning your comment about Bug #12629, do we agree that we will have a or several reproducers?
>
> No decision was made yet wrt. who reproduces and who compares the results, and so far anonym and me disagreed on fundamental matters on that ticket, so let’s not assume anything at this point.

Hm. But what we can assume is that we can compare the ISO checksums from an ISO built on a build machine with the one built by the RM?

> “could even one of the chefs have been compromised and unknowingly use a vegetable which will make all of us sick and at least get a stomach ache? That’s what reproducible builds help verify and protect against” is incorrect I think: in the current state of thing (see Bug #12629) we trust at least the RM and their machine/system

I think this sentence is here to explain what reproducible builds do in general though.

However, I understand that I should add something like “we need to trust the chef cook until Bug #12629 is solved”. But I’m not sure I want to write that like this - as the blogpost is supposed to make reproducible builds easy to understand and this will again add quite some complexity. Still, I agree that we should not sell “reproducible build” as “secure magic”. Any ideas how we can tell a nontechnical user about this?

#24 Updated by intrigeri 2017-10-21 08:39:15

• Assignee deleted (intrigeri)
• QA Check changed from Info Needed to Dev Needed

Hi!

> intrigeri wrote:
>> > Concerning your comment about Bug #12629, do we agree that we will have a or several reproducers?

>> No decision was made yet wrt. who reproduces and who compares the results, and so far anonym and me disagreed on fundamental matters on that ticket, so let’s not assume anything at this point.

> Hm. But what we can assume is that we can compare the ISO checksums from an ISO built on a build machine with the one built by the RM?

(I’m not sure I understand your question so if my answer below is off-topic, please rephrase :)

We can assume one can do this comparison (as documented) after a release, by checking out the tag, building their own ISO and comparing it to the one we’ve released.

>> “could even one of the chefs have been compromised and unknowingly use a vegetable which will make all of us sick and at least get a stomach ache? That’s what reproducible builds help verify and protect against” is incorrect I think: in the current state of thing (see Bug #12629) we trust at least the RM and their machine/system

> I think this sentence is here to explain what reproducible builds do in general though.

Yes, that’s one of the things reproducible builds can provide in theory. It’s simply that our implementation doesn’t. I didn’t look at the text again, so if you’re confident that the reader won’t incorrectly infer “reprobuilds allow this ⇒ Tails reproducible builds provide it”, I’m fine with describing theoretical properties of reproducible builds that don’t apply to our implementation. Your call :)

> However, I understand that I should add something like “we need to trust the chef cook until Bug #12629 is solved”.

Well, not really. The current state of things (on which anonym & I seem to agree on) is that:

• once Bug #12629 is solved, we will be protecting against a compromise of the RM’s system/hardware;
• we don’t try to protect against a compromise of the RM person, and IIRC it’s not part of the plan on Bug #12629 to try to protect against this (while discussing this topic there we realized that there were other big process/technical blockers anyway, it’s not just a matter of documenting stuff).

> But I’m not sure I want to write that like this - as the blogpost is supposed to make reproducible builds easy to understand and this will again add quite some complexity. Still, I agree that we should not sell “reproducible build” as “secure magic”. Any ideas how we can tell a nontechnical user about this?

(Without looking at the text again) I think I would solve this by removing the over-optimistic pieces rather than by adding the more detailed explanations that would be needed to avoid making promises we’re not planning to honor.

#26 Updated by Anonymous 2017-10-24 12:06:52

• Assignee set to intrigeri
• QA Check changed from Dev Needed to Ready for QA

Would you like to re-read it one last time please? I think I removed the last offending bits :) I plan to publish this on November 17th (after the release of 3.3).

#30 Updated by intrigeri 2017-11-08 20:42:46

• Assignee deleted (intrigeri)
• QA Check changed from Ready for QA to Dev Needed

Looks good to me except after the discussions we’ve had at the reproducible builds summit, it feels wrong to pretend we turn “source code” into an ISO. I think we should clarify that our input is not source code. Sorry!

#31 Updated by intrigeri 2017-11-15 09:13:59

• Assignee set to intrigeri

intrigeri wrote:
> Looks good to me except after the discussions we’ve had at the reproducible builds summit, it feels wrong to pretend we turn “source code” into an ISO. I think we should clarify that our input is not source code. Sorry!

I’ll draft something.

#32 Updated by intrigeri 2017-11-15 09:31:53

• Assignee deleted (intrigeri)
• % Done changed from 60 to 70
• QA Check changed from Dev Needed to Ready for QA
• Feature Branch changed from 451f:tails/feature/12356+reproducible_blog_post to feature/12356+reproducible_blog_post

Done! :)

#33 Updated by anonym 2017-11-15 11:30:52

• Target version changed from Tails_3.3 to Tails_3.5

#34 Updated by intrigeri 2017-11-15 15:14:08

• blocks deleted (Bug #12629: Document reproducible release process)

#35 Updated by intrigeri 2017-11-15 15:15:01

• Status changed from In Progress to Resolved
• % Done changed from 70 to 100
• QA Check changed from Ready for QA to Pass

This got published today, and later amended to document a known reproducibility issue that had been discovered yesterday but not documented yet.