Project

General

Profile

Feature #11990

Feature #5630: Reproducible builds

In 2018, try reproducing an ISO that was released in 2017

Added by intrigeri over 1 year ago. Updated 11 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/22/2016
Due date:
% Done:

0%

QA Check:
Dev Needed
Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

In 2017 we'll be releasing ISO images that build reproducibly… but we won't have tried year variations. So, in 2018, let's try to rebuild an ISO that was released in 2017.

History

#1 Updated by intrigeri over 1 year ago

#2 Updated by intrigeri 5 months ago

  • Target version changed from 2018 to Tails_3.5

#3 Updated by intrigeri about 2 months ago

#4 Updated by intrigeri about 2 months ago

  • Parent task set to #5630

#5 Updated by intrigeri about 2 months ago

  • Assignee changed from intrigeri to anonym

I wanted to do that (thanks to the feature/tails-3.3 branch) but I can't: my laptop's ISO build setup has been broken for 1.5 months (the VM freezes at some point in the build, when my CPU is throttled) and my local Jenkins setup, just like our shared one, ignores branches that have no commit on top of our main branches. I think it'll be super easy for you to test this, so perhaps you can take it over from me?

#6 Updated by anonym 29 days ago

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

#7 Updated by anonym 20 days ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 20
  • QA Check set to Info Needed

First I wanted to try reproducing Tails 3.2, since Tails 3.3 is affected by #14933, but that quickly failed since we do not have #12452. With uncommitted hacks to vagrant/provision/setup-tails-builder and setting TAILS_BUILD_OPTIONS="dateoffset=-129 ignorechanges" I at least got the wiki built, and past debootstrapping, but then the first apt update made by live-build failed with EXPKEYSIG. So, we need to add a unauthenticated_apt option that propagates all the way into the build scripts. Trying any version earlier than 3.2 will have the same problem.

The only other candidate for this ticket is Tails 3.3, which is affected by #14933. For that release I uploaded the image I built locally, not what Jenkins built, and since I built without TAILS_BUILD_OPTIONS="mergebasebranch", my image is unreproducible. I have at least verified that #14933 is the only difference with the rebuild I just did. Sadly we do not still have Jenkins' build of Tails 3.3 around, cause I should be able to reproduce it. :/

Actually, I don't think the year change is what matters, which is what this ticket assumes. I suggest we:

  • rename this ticket "Try reproducing an ISO that was released six months ago".
  • get #12452 into Tails 3.6.
  • postpone this ticket to Tails 3.6's release date + six months (= during the 3.10 cycle), and then try to reproduce Tails 3.6 specifically.

What do you think?

#8 Updated by intrigeri 19 days ago

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

Actually, I don't think the year change is what matters, which is what this ticket assumes.

Well, the very purpose of this ticket was to exercise the only date variation we've not tried yet, that is changing year. That's in case something in our build process produces different results depending on the year when the build is started (e.g. if the year, but not the day nor the month, is embedded or impacts something somewhere in the ISO).

  • rename this ticket "Try reproducing an ISO that was released six months ago".

IIRC ensuring 6-months old ISO images can be reproduced was not part of our goals for this project.

So to me it looks like our only option is to postpone this to early 2019.

#9 Updated by anonym 11 days ago

  • Status changed from In Progress to Confirmed
  • Target version changed from Tails_3.6 to Tails_3.12
  • % Done changed from 20 to 0

intrigeri wrote:

Actually, I don't think the year change is what matters, which is what this ticket assumes.

Well, the very purpose of this ticket was to exercise the only date variation we've not tried yet, that is changing year. That's in case something in our build process produces different results depending on the year when the build is started (e.g. if the year, but not the day nor the month, is embedded or impacts something somewhere in the ISO).

Ok, fair enough.

  • rename this ticket "Try reproducing an ISO that was released six months ago".

IIRC ensuring 6-months old ISO images can be reproduced was not part of our goals for this project.

Ok, I vaguely recall us talking about aiming for that time frame. Any way, if we just solve #12452 I think we'll get a lot for very little effort.

So to me it looks like our only option is to postpone this to early 2019.

Ack! I'll encode that as 3.12, a "dummy" for the first release in 2019.

#10 Updated by anonym 11 days ago

Off-topic:

anonym wrote:

Any way, if we just solve #12452 I think we'll get a lot for very little effort.

FWIW, the "little effort" part is dubious: #12452#note-6

Also available in: Atom PDF