[rb-general] [PATCH] Document timestamp clamping
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Nov 4 20:19:49 CET 2016
On Fri 2016-11-04 12:53:19 -0400, Holger Levsen wrote:
> On Fri, Nov 04, 2016 at 10:32:37AM -0400, Daniel Kahn Gillmor wrote:
>> I think clamping is the right thing to do, which means i think the spec
>> is currently wrong. We should fix it. Just because it's a rare case
>> doesn't mean it should be ignored.
> I must say that the logic of these two paragraphs sounds very
> compelling. I'm not fully convinced yet, that clamping is right and the
> spec is wrong though. Can you summarize clamping in one simple sentence?
+ Where build processes embed timestamps that are not
+ "current", but are somehow related to the source and
+ the build processes, they MUST use a timestamp no later
+ than <envar>SOURCE_DATE_EPOCH</envar>.
But you knew i was going to say that, right? :P
Even "simpler" if you want that, would be to re-cast the entire spec as
a clamping spec, since "current" is just a special case of clamping:
Everywhere that the build process records a timestamp, that
timestamp should be no greater than SOURCE_DATE_EPOCH.
but if you want to acknowledge nuance, you have to add a parenthetical
... records a timestamp (that is not intended to be "in the
This is because some software is distributed with specific timestamps
that are relevant to the future -- for example, a certain feature might
sunset on a certain day, or perhaps the software contains a table of
And of course, in practice, there are intermediate build systems that
absolutely do need to distinguish between timestamps happening *during
build* (e.g. make) that would be disastrous if we set them all to
SOURCE_DATE_EPOCH. So we probably should change "records a timestamp"
to "records a timestamp that will be distributed in the generated binary
With yet more nuance, we might also want to say that we expect
SOURCE_DATE_EPOCH itself to be no later than the actual current time --
that is, we don't expect someone in 2016 to build a package with a
SOURCE_DATE_EPOCH in 2020. These specs will fall apart and fail to
provide reproducibility in that case.
I'm sure there are phrasings that are better than these feeble attempts,
though. I welcome alternative proposals.
More information about the rb-general