Make the Unix build process more repeatable

[ngie-eign]

Before this change all manpages would contain the date when pod2man was
run. This resulted in outputs that differed between builds--or
potentially across a single build if the host clock "ticked" to the next
day when the build was being run.

This commit modifies the manpage generation process as follows:

• The date all manpages were generated will be normalized to a single
  date instead of a potentially rolling date.
• The release date specified in VERSION.dat is used instead of the
  date/time when pod2man was executed OR--in the event a date
  isn't specified in VERSION.dat--the time when the Makefiles were
  last regenerated.

Embedding a consistent date into the generated manpages helps ensure that
the build process as a whole is more repeatable and helps ensure that
release versions of OpenSSL create artifacts consistent with the date
that the official release was cut.

Closes: #28323

[kroeckx]

I'm wondering what the effect is when VERSION.dat doesn't contain a date, like in the current branch.

In Debian, we set the SOURCE_DATE_EPOCH, which is based on the debian/changelog file. It would now get an other date, when upstream released it, instead of when Debian did, which looks fine to me.

[t8m]

It is borderline on what we would accept with CLA: trivial. Please consider signing a CLA. https://openssl-library.org/policies/cla/index.html

[levitte]

I'm wondering what the effect is when VERSION.dat doesn't contain a date, like in the current branch.

my $t = $config{"release_date"}
      ? Time::Piece->strptime($config{"release_date"}, "%d %b %Y")
      : localtime;
$t->strftime("%Y-%m-%d")

When the release date ($config{"release_date"}) is empty, it's falsy, so localtime will be used to determine the date.

[levitte]

It is borderline on what we would accept with CLA: trivial. Please consider signing a CLA. https://openssl-library.org/policies/cla/index.html

I could accept it with CLA: trivial

[kroeckx]

So if we ever decide to shipped a non-released version, which seems unlikely, this will make it non-reproducible.

[ngie-eign]

It is borderline on what we would accept with CLA: trivial. Please consider signing a CLA. https://openssl-library.org/policies/cla/index.html

I could accept it with CLA: trivial

I submitted my individual CLA just last night. The second commit doesn't contain that metadata because I planned on squashing the second commit to the first one (which has the metadata) prior to merge.

[ngie-eign]

So if we ever decide to shipped a non-released version, which seems unlikely, this will make it non-reproducible.

Yes. That seems extremely unlikely though, since releasing sources without a fixed version to the public would be contradictory.

Background for other readers: multiple OSes out there (I can speak directly to FreeBSD and a FreeBSD variant I develop on for work) keep patches which normalize dates to deterministic values in order to make builds reproducible. This is sometimes done for to simplify binary patching processes.

[t8m]

Merged to all the active branches. Thank you for your contribution.