Debian and SOURCE_DATE_EPOCH=0

[Marek Marczykowski-Górecki]

On Fri, Feb 20, 2026 at 04:31:22PM -0500, David A. Wheeler via rb-general wrote:
> 
> 
> > On Feb 20, 2026, at 12:37 PM, Vagrant Cascadian <vagrant at reproducible-builds.org> wrote:
> > 
> > In my opinion, SOURCE_DATE_EPOCH should really be a timestamp of last
> > resort, the preferred thing is to not include build timestamps at all!
> 
> It's easier to reproduce data if there are no timestamps embedded in it, sure.
> 
> However, receivers generally don't perceive these timestamps as "build" timestamps.
> They aren't marked that way. They are simply "timestamps", and are required parts
> of many formats (zip and tar for example). The real goal is to make them reproducible.
> That can be done with:
> 
> * Meaningless reproducible value (like "1")
> * Meaningful reproducible value (e.g., datetime of last git commit in source)
> 
> I personally think that providing end-users with meaningful data, when we can,
> is helpful. Users often don't get enough meaningful data!
> But this is a personal preference that different people can conclude differently
> (even the same person for different circumstances!). It's yet another trade-off.
> 
> What matters, in the end, is reproducibility so we can eliminate
> a variety of attacks.

Honestly, the argument about comparing resulting binaries _across
different versions_ is very appealing to me. For example, given the
classic example of CVE-2002-0083, not having a bunch of timestamp
differences would greatly ease verifying if new binary is really patched
(and if that's the only behavior change! especially important for QA
reasons). Doing separate build, with modified SOURCE_DATE_EPOCH, just
for comparing, isn't always realistic option. After all, usually you'd
want to verify what is actually going to be installed (for example:
package from debian-security repository), not some temporary build.

While "last source change date" may be interesting information in some
cases, the package metadata already includes this information. I don't think
there is really a need to include it in the package payload too. Some
constant value (same across different versions) should work just fine,
as long as it's legal in all places that really need some timestamp
value (like tar archives). The last part apparently is not trivial based
on this very thread, though...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260220/2add45ba/attachment.sig>