Bug #8204

Add a link to reproducible builds blogpost or verification instructions to our about page

Added by sajolida 2014-11-04 21:01:32 . Updated 2019-02-20 20:17:32 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

In our page “Trusting Tails”, in the section “Free software and public
scrutiny”, we pretend that having our source code is a way to recompile
our binaries and compare them with the one that we serve: “Furthermore,
with the source code it is possible to build the software, and then
compare the result against any version that is already built and being
distributed”.

This is not true for the moment, at least until we have reproducible builds.

While working on this we should also point this page to our actual
source code.

Subtasks

History

#1 Updated by intrigeri 2014-11-05 08:09:53

> “Furthermore, with the source code it is possible to build the
> software, and then compare the result against any version that is
> already built and being distributed”.

> This is not true for the moment, at least until we have reproducible builds.

Well, it’s not a trivial byte-to-byte comparison, but it is possible. We’ve even used this possibility at least twice to avoid running the entire manual testing update, in some occasions when we had to rebuild an already tested candidate ISO.

#2 Updated by sajolida 2014-11-05 17:23:13

What do you mean by that exactly? I need to understand it better to know
if we can reject this ticket or if we still need to fix the doc.

By “build the software and comparing the result” I meant building an ISO
image and comparing it. I guess that even a small delta during build
(say a timestamp) might generate an incomprehensible diff once
compressed in squashfs and integrated in an ISO image. Am I right?

When you say that it is possible to do non byte-to-byte comparison, what
are you referring to? Opening the ISO and the squashfs and comparing
their files?

Using such technique, would it be possible to validate an entire
official ISO image? Just an example coming to my mind: would it be
possible for example to validate the Virtual Box kernel modules which
are complied during build?

#3 Updated by intrigeri 2014-11-06 09:54:46

> I guess that even a small delta during build (say a timestamp) might generate an incomprehensible diff once compressed in squashfs and integrated in an ISO image. Am I right?

Yes.

> When you say that it is possible to do non byte-to-byte comparison, what are you referring to? Opening the ISO and the squashfs and comparing their files?

Yes.

> Using such technique, would it be possible to validate an entire official ISO image? Just an example coming to my mind: would it be possible for example to validate the Virtual Box kernel modules which are complied during build?

I don’t know (and TBH I doubt it, so perhaps my point was overly optimistic, indeed).
Maybe ask anonym, who did this comparison at least twice?

#4 Updated by sajolida 2014-11-06 16:53:08

  • Assignee set to anonym
  • QA Check set to Info Needed

#5 Updated by BitingBird 2015-01-11 00:57:14

  • Type of work changed from End-user documentation to Contributors documentation

#6 Updated by intrigeri 2015-01-11 09:36:49

  • Type of work changed from Contributors documentation to End-user documentation

#7 Updated by anonym 2015-03-13 01:55:07

  • Assignee changed from anonym to sajolida
  • QA Check deleted (Info Needed)

WTF, I’m sure I answered this months ago.

intrigeri wrote:
> > Using such technique, would it be possible to validate an entire official ISO image? Just an example coming to my mind: would it be possible for example to validate the Virtual Box kernel modules which are complied during build?
>
> I don’t know (and TBH I doubt it, so perhaps my point was overly optimistic, indeed).
> Maybe ask anonym, who did this comparison at least twice?

Such modules become identical.

Just to say something about this, FWIW, there’s a few places where timestamps/checksums/similar differ in files that are easily diffable. When it comes to binary file, which are harder to diff, it’s surprisingly little. Examples:

  • lots of irrelevant stuff in /dev
  • {pubring,secring,trustdb}.gpg (e.g. for monkeysphere) which isn’t strange
  • font and manpages caches
  • .mo files for translations (easily spotted timestamp)
  • some certificates in /etc/ssl/certs are generated after at package installation time
  • some Java files are generated at package installation time

To have a hands-on look:

mkdir /tmp/iso1 /tmp/iso2 /tmp/fs1 /tmp/fs2
sudo mount -o loop $ISO1 /tmp/iso1
sudo mount -o loop $ISO2 /tmp/iso2
sudo mount -o loop /tmp/iso1/live/filesystem.squashfs /tmp/fs1
sudo mount -o loop /tmp/iso2/live/filesystem.squashfs /tmp/fs2
diff -qr /tmp/iso1 /tmp/iso2
diff -qr /tmp/fs1 /tmp/fs2

#8 Updated by BitingBird 2015-03-15 21:39:33

So… this ticket is not really needed, as our actual page doesn’t really lie ?

#9 Updated by anonym 2015-03-24 08:40:17

I’m not sure. Perhaps the wording in that article still should be downplayed a bit. To do the comparison I showed above, one has to build the image essentially at the same time as we build it, so that the Debian and Tor Project APT repos are in the same state. Doing that later is complicated: one could use snapshot.debian.org for the Debian repos, but for the Tor Project’s. Feature #5926 would help, but we’re not there yet.

#10 Updated by Anonymous 2018-01-17 16:40:34

  • Subject changed from Be less optimistic regarding source code verification to Add a link to reproducible builds blogpost or verification instructions to our about page
  • QA Check set to Info Needed

We now have reproducible builds, so we should probably simply add a link to our verification instructions or the blogpost explaining reproducible builds to this page: https://tails.boum.org/doc/about/trust/ What do you think?

#11 Updated by sajolida 2019-01-08 12:38:31

  • blocks Feature #15941: Core work 2018Q4 → 2019Q2: Technical writing added

#12 Updated by sajolida 2019-01-08 12:38:56

  • Target version set to Tails_3.12
  • QA Check deleted (Info Needed)

A minimal version of this can qualify as core work.

#13 Updated by sajolida 2019-01-28 18:45:32

  • Target version changed from Tails_3.12 to Tails_3.13

#14 Updated by sajolida 2019-02-20 20:17:32

  • Assignee deleted (sajolida)
  • Target version deleted (Tails_3.13)

Actually, we’re too busy and it’s less important than the rest of our plate.

#15 Updated by sajolida 2019-02-20 20:17:38

  • blocked by deleted (Feature #15941: Core work 2018Q4 → 2019Q2: Technical writing)