Closed nl6720 closed 6 months ago
The hash seed is not actually time based (it's a random value), so it seems at odds with the definition of SOURCE_DATE_EPOCH to say that we should change how the hash seed is generated. I understand why this would be considered "convenient", but it still seems strange.
so it seems at odds with the definition of SOURCE_DATE_EPOCH to say that we should change how the hash seed is generated
I agree, using time as seed only in this case would be somewhat unexpected.
But I would really love to see SOURCE_DATE_EPOCH
respected, and support for timestamp clamping seems to be a great idea, too.
SOURCE_DATE_EPOCH has been implementing with timestamp clamping in v1.47.1-rc1+
e1f7100643a46456be107b33098f6034b0835e6d added support for a e2fsprogs-specific variable
E2FSPROGS_FAKE_TIME
. But as the commit message says, you still need to manually set a reproducible hash seed.It would be useful if e2fsprogs could support
SOURCE_DATE_EPOCH
. I.e. ifSOURCE_DATE_EPOCH
is set, use it as the mkfs timestamp and generate a reproducible hash seed from it.Additionally,
mkfs.ext4 -d
reproducibility requires timestamp clamping. The various timestamps of files in the file system should not be newer thanSOURCE_DATE_EPOCH
.