Hi kre, > As I said, I know (somewhat) the -d parser on netbsd, which I know > handles the @N form, but I kind of doubt has much in the way of error > checking there.
No, it calls the hoary parsedate(3), http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/date/date.c?rev=1.61&content-type=text/x-cvsweb-markup&only_with_tag=MAIN http://netbsd.gw.com/cgi-bin/man-cgi?parsedate++NetBSD-current but despite the man page, it's not obvious to me that the `epochdate' rule indicates the gmtime_r(3) error. http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/parsedate.y?rev=1.32&content-type=text/x-cvsweb-markup GNU date also accepts text that doesn't match the Reproducible-Builds spec. $ date -ud '@ 003.1415' 1970-01-01 00:00:03 +0000 Thu > If you really believe in that, then you need to do the validation. Here's the specification again. https://reproducible-builds.org/specs/source-date-epoch/#idm53 It doesn't sufficiently spell out what's valid. The value MUST be an ASCII representation of an integer with no fractional component, identical to the output format of date +%s. So that means it matches /^(0|-?[1-9][0-9]*)$/ in the interval [-67768040609740800, 67768036191676800) given a 64-bit signed time_t with a 32-bit signed year. (Though POSIX doesn't state time_t need be bigger than 32 bits, or if it's signed.) It SHOULD be set to the last modification time of the source, incorporating any packaging-specific modifications. That would bring it back into reasonable bounds, but it's only a SHOULD. I'm thinking if it matches the above regexp, and gmtime(3) is happy, then that's good enough. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
