ParseSourceDateEpoch used strconv.ParseInt, which accepts a leading sign, so a
negative SOURCE_DATE_EPOCH was silently accepted and produced a pre-1970
timestamp with a nil error. That contradicts the function's own doc ("returns
an error if ... not well-formatted") and the reproducible-builds spec, where
SOURCE_DATE_EPOCH is a non-negative number of seconds since the Unix epoch.
Reject negative values and add a regression test.
Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
This introduces a ParseSourceDateEpoch function, which can be used
to parse "SOURCE_DATE_EPOCH" values for situations where those
values are not passed through an env-var (or the env-var has been
read through other means).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These tests were failing on my macOS; could be the precision issue (like on
Windows), or just because they're "too fast".
=== RUN TestSourceDateEpoch/WithoutSourceDateEpoch
epoch_test.go:51:
Error Trace: /Users/thajeztah/go/src/github.com/containerd/containerd/pkg/epoch/epoch_test.go:51
Error: Should be true
Test: TestSourceDateEpoch/WithoutSourceDateEpoch
Messages: now: 2023-06-23 11:47:09.93118 +0000 UTC, v: 2023-06-23 11:47:09.93118 +0000 UTC
This patch:
- updates the rightAfter utility to allow the timestamps to be "equal"
- updates the asserts to provide some details about the timestamps
- uses UTC for the value we're comparing to, to match the timestamps
that are generated.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For determinism of human-readable string representation.
e.g., "2023-01-10T12:34:56Z" vs "2023-01-10T21:34:56+09:00"
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Nikolaus Schuetz