Tails

#1 Updated by intrigeri 2016-11-22 14:01:08

• blocked by Feature #5630: Reproducible builds added

#2 Updated by intrigeri 2017-09-28 12:13:16

• Target version changed from 2018 to Tails_3.5

#3 Updated by intrigeri 2018-01-02 09:12:44

• blocks deleted (Feature #5630: Reproducible builds)

#4 Updated by intrigeri 2018-01-02 09:12:59

• Parent task set to Feature #5630
• Deliverable for set to SponsorS_Internal

#5 Updated by intrigeri 2018-01-02 15:34:18

• 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 2018-01-23 19:52:26

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

#7 Updated by anonym 2018-02-01 11:25:42

• 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 Bug #14933, but that quickly failed since we do not have Bug #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 Bug #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 Bug #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 Bug #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 2018-02-03 07:22:42

• 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 2018-02-10 23:08:10

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

#11 Updated by intrigeri 2018-04-08 17:23:03

• Subject changed from In 2018, try reproducing an ISO that was released in 2017 to In 2019, try reproducing an ISO that was released in 2018
• Parent task deleted (Feature #5630)

(We now have reproducible builds so let’s try to close Feature #5630 at some point.)

#12 Updated by intrigeri 2018-04-08 18:35:52

• Deliverable for changed from SponsorS_Internal to 289

#13 Updated by anonym 2019-01-09 10:41:24

• Status changed from Confirmed to Resolved
• Assignee deleted (anonym)
• % Done changed from 0 to 100
• QA Check changed from Dev Needed to Pass

I just successfully reproduced 3.10.1. Sadly this is not the last blocker for Feature #5630.