Debian and SOURCE_DATE_EPOCH=0

[John Gilmore]

"David A. Wheeler via rb-general" wrote:
> I personally prefer a "meaningful" datetime stamp, since that provides
> additional information. But that's a preference about maximally providing
> info; clearly choosing "1" can also provide reproducibility
> 
> Can these trade-offs be documented somewhere on the r-b website
> with SOURCE_DATE_EPOCH? Basically:
> 
> * Many prefer setting SOURCE_DATE_EPOCH, MTIME, and --mtime to a
>   "meaningful" value like `git show HEAD --format=%ct --no-patch`
>   as this provides additional information.

There is a step beyond bit-for-bit reproducibility that I think it would
be wise for us to enable.

That is the ability to patch something or a few things (e.g. close major
security bugs), rebuild the world, and then be able to see with "diff
-r" just the small set of changes that those bug-fixes made in the
generated binaries and files.  Without an ocean of chaff from shifting
timestamps in unrelated files.

Using `git show HEAD` to create the timestamp means that you can't patch
a bug, rebuild, and see what changed -- because every timestamp embedded
in the generated files will change.  (This is the same problem that
reproducible-builds are trying to solve for the case when NO patch has
been applied.  Can we simultaneously solve it for when there ARE
patches?)

Git is designed and used to record all changes to a package in a well
documented way.  Making distros' embedded timestamps depend on never
touching git seems like something we wouldn't want to encourage.  Why
would we force a distro's security maintainer to make their patches
WITHOUT touching any package's git repo?

I wrote about doing this in an old email (which I can't find now) about
enabling maintainers to patch a few major bugs in a distribution, and
then rebuild the whole distro to be able to "diff" exactly what effect
their patches would create on the whole distro.  This especially matters
when changing an include file or a library, since it's sometimes hard to
know what obscure parts of the distro might be depending on particular
macros or definitions in particular include files.

Distros regularly go through "point releases" that patch major bugs but
do nothing else.  If our reproducibility changes force embedded
timestamps to shift whenever such a point-release is made, even for
files that never changed, we will have also forced the diff between the
original release and the point release to be (uselessly) much larger
than it needed to be to actually fix the bugs.

Thanks for listening!

	John