Feature #12339
Have the ISO build reproducibility regardless of the current time
100%
Description
Subtasks
Related issues
Related to Tails - |
Resolved | 2017-03-16 |
History
#1 Updated by intrigeri 2017-03-15 06:02:07
- Status changed from Confirmed to In Progress
- Assignee set to intrigeri
- % Done changed from 0 to 10
This can’t work as we encode AMNESIA_FULL_VERSION
, that includes today’s date, in the rootfs.
#2 Updated by intrigeri 2017-03-15 06:20:52
- Subject changed from Test ISO build reproducibility when building on a different date to Have the ISO build reproducibility regardless of the current time
#3 Updated by intrigeri 2017-03-15 06:21:03
- Type of work changed from Test to Code
#4 Updated by intrigeri 2017-03-15 10:55:25
- % Done changed from 10 to 20
I’ve tested building 18 days in the future, and everything’s fine except /etc/shadow
, for which lamby has just sent a patch
Next steps:
- apply this patch
- test a build happening on a different year
#5 Updated by intrigeri 2017-03-15 13:45:19
- Assignee changed from intrigeri to lamby
The patched shadow
package addresses the /etc/shadow
problem for users that are created after live-build has upgraded shadow
from the (Debian Stretch) one it installed during debootstrap to our custom one. But during debootstrap, a bunch of users are created and their sp_lstchg
encodes the build date. So I think we need to use chage
in config/chroot_local-hooks/99-zzzzzz_reproducible-builds-post-processing
after all.
#6 Updated by lamby 2017-03-15 13:50:08
I will first try and fix debootstrap as that’s much cleaner and upstream.. otherwise, yes, post-processing
#7 Updated by lamby 2017-03-15 14:29:42
I misread. Tails will need to post-process until this hits stretch or whatever distribution is being debootstrapped.
#9 Updated by intrigeri 2017-03-15 16:07:57
- Assignee changed from lamby to intrigeri
- % Done changed from 20 to 30
/etc/shadow
is now OK :)
Last thing I want to test: a build happening on a different year.
#10 Updated by intrigeri 2017-03-16 08:51:48
- % Done changed from 30 to 40
Building last year (i.e. before S_D_E
) yields a different ISO, which is expected since we only clamp mtimes to S_D_E
. Thankfully it’s not a use case we need to support in practice, so I’m going to test building next year.
Also, adding a sanity check early in the build that will error out if current time is before S_D_E
, because this breaks not only build reproducibility, but probably a number of more or less implicit assumptions our hacks for Feature #5630 make.
#11 Updated by intrigeri 2017-03-16 09:37:34
- related to
Feature #12351: Test building an ISO with a fake system time set in 2018 added
#12 Updated by intrigeri 2017-03-16 09:40:14
- Status changed from In Progress to Resolved
- Assignee deleted (
intrigeri) - % Done changed from 40 to 100
intrigeri wrote:
> so I’m going to test building next year.
Too painful, will do it later this year when it’ll be easy (Feature #12351).
> Also, adding a sanity check early in the build that will error out if current time is before S_D_E
, because this breaks not only build reproducibility, but probably a number of more or less implicit assumptions our hacks for Feature #5630 make.
Now tracked as Feature #12352.
So marking this as resolved as all remaining bits are tracked elsewhere.