Project

General

Profile

Feature #12356

Communicate about reproducible builds to users via a blog post

Added by u 9 months ago. Updated 27 days ago.

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

100%

QA Check:
Pass
Feature Branch:
feature/12356+reproducible_blog_post
Type of work:
Communicate
Blueprint:
Starter:
No
Affected tool:

Description

possibly in the news and on Twiter.


Related issues

Related to Tails - Feature #12355: Communicate about RB efforts to RB community Duplicate 03/17/2017
Related to Tails - Bug #14831: Write blogposts for the donation campaign Resolved 10/11/2017
Related to Tails - Feature #12626: Report back to the reproducible builds community about how we did it Resolved 05/31/2017
Related to Tails - Feature #12035: Donation campaign 2017 In Progress 08/01/2015

Associated revisions

Revision dc1420be (diff)
Added by intrigeri 27 days ago

Fix capitalization of blog post URL (refs: #12356).

Revision 6a048f3b (diff)
Added by intrigeri 27 days ago

Don't pretend we build everything from source (refs: #12356)

Revision df5bea97 (diff)
Added by intrigeri 27 days ago

Use terminology that will survive the move to WebExtensions (refs: #12356)

Revision 31acc10b (diff)
Added by intrigeri 27 days ago

Point to the actual report rather than its (draft) blueprint (refs: #12356)

Revision aff72ae6 (diff)
Added by intrigeri 27 days ago

Also mention partnerships + insist on individual donations (refs: #12356)

Revision e010d563 (diff)
Added by intrigeri 27 days ago

Fix link to donation page (refs: #12356)

"donate.en.html" only works with "usedirs: 0", e.g. on the static website
included in our ISO. But our production website has "usedirs: 1" (which is
needed for language negotiation).

Revision ca14a86b (diff)
Added by intrigeri 27 days ago

Be more catchy (refs: #12356)

History

#1 Updated by u 9 months ago

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

#2 Updated by u 6 months ago

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

#3 Updated by u 3 months ago

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

This shall happen right after 3.2

#5 Updated by intrigeri 2 months ago

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

#6 Updated by u 2 months ago

  • 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 u 2 months ago

  • Status changed from Confirmed to In Progress

#8 Updated by u 2 months ago

  • Assignee changed from u 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 u 2 months ago

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

#10 Updated by anonym 2 months ago

  • Assignee changed from anonym to u
  • % 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 u 2 months ago

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

#12 Updated by u 2 months ago

Great! Thanks for the review. I've implemented all of your suggestions.

#13 Updated by u 2 months ago

anonym wrote:

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:

That was a good idea! Thanks :)

#14 Updated by u 2 months ago

  • Assignee changed from u 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 u 2 months ago

#16 Updated by u 2 months ago

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

#17 Updated by intrigeri about 2 months ago

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

OK. I guess it's better if I review this earlier though, so you have time to fix any blocking issue I might notice early enough so we're ready to publish this ASAP after 3.3 is out. If my assumptions are incorrect (e.g. if you won't have time anyway to work on this again during this cycle) let me know and I'll postpone to 3.4.

#18 Updated by intrigeri about 2 months ago

  • Assignee changed from intrigeri to u
  • 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 #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 u about 2 months ago

  • 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 #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 u about 2 months ago

  • Assignee changed from u to intrigeri

#21 Updated by intrigeri about 2 months ago

Concerning your comment about #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.

#22 Updated by intrigeri about 2 months ago

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

#23 Updated by u about 2 months ago

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

intrigeri wrote:

Concerning your comment about #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 #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 #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 about 2 months ago

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

Hi!

intrigeri wrote:

Concerning your comment about #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 #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 #12629 is solved".

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

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

#25 Updated by u about 2 months ago

Ok, understood! Thanks for the clarifications.

#26 Updated by u about 2 months ago

  • Assignee changed from u 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).

#27 Updated by intrigeri about 2 months ago

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 3rd.

Ideally, indeed I would like to do a final review, but I am not available for this before Nov 5.
I thought the plan was to publish this later ("Let's not merge it before Tails 3.3 is out though").

#28 Updated by u about 2 months ago

intrigeri, yes, "November 3rd" was a mistake (which you probably read in the email you received from Redmine without getting back to read my updtaed comment). I corrected it 3 seconds later -> the publication date is the 17th of November. So you do have some time.

#29 Updated by intrigeri about 2 months ago

Perfect, will do then :)

#30 Updated by intrigeri about 1 month ago

  • Assignee changed from intrigeri to u
  • 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 27 days ago

  • Assignee changed from u 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 27 days ago

  • Assignee changed from intrigeri to u
  • % 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 27 days ago

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

#34 Updated by intrigeri 27 days ago

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

#35 Updated by intrigeri 27 days ago

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

Also available in: Atom PDF