[rb-general] [PATCH] Document timestamp clamping

[HW42]

Daniel Kahn Gillmor:
> 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.

Given that it's used in a bunch of cases I think it's reasonable to
include it in the spec.

>> 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?
> 
> Sure:
> 
> +			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.

See comment at the end.

> but if you want to acknowledge nuance, you have to add a parenthetical
> aside:
> 
>     ... records a timestamp (that is not intended to be "in the
>     future"), ...
> 
> 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
> astronomical events.
> 
> 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
> artifact".

"record a timestamp which might depends on the build time ..."; This
should cover cases like the astronomic dates.

> 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.

I think clamping to SDE should not be the default. In my opinion the
options for timestamps which otherwise might depend on the build date
are (most desirable first):

1) Drop them!
2) Set to SDE.
3) Clamp to SDE.

I think clamping is worser than setting in the general case because

 - I'm not very convinced that it's actually useful in most cases.

 - It depends on the filesystem. For example FAT has only two seconds
   resolution, most archive formats one second, ext4 IIRC nano second
   resolution.
 - It's fragile to otherwise innocent operations like touch, $EDITOR
   (without changing content), cp, ...
 - Consistent clocks are tricky ;P
 - Setting a date in the future is sometimes reasonable. Like a LaTeX
   document with a fixed publishing date, or some software with a fixed
   release date. (Sure you can achieve this via other means but SDE is a
   convenient way)
 - (for example) git breaks clamping to SDE

So in my point of view like "set date to SDE" itself clamping is a
work-around to fulfill given constraints (like "but I want build
dates!") while still keeping it reproducible. But I prefer setting to a
fixed date. So I don't think we should modify the existing semantic of
the spec (but adding as an alternative is IMO ok). Also I'm not very
convinced about the must not be in the future point yet.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 825 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20161106/840e1459/attachment.sig>