commit 4c984bc7664755d701c75b49b795678e164551e3
author Nico Weber <thakis@chromium.org> Wed Aug 15 22:27:02 2018
committer Commit Bot <commit-bot@chromium.org> Wed Aug 15 22:27:02 2018
tree b7df27bf6be29bb500790266208f36799d563da1
parent e0903d18987a24ef8003d758ac0c3ac3f6cf3ec5

Make BUILD_DATE based off the last commit time instead of the current time.

BUILD_DATE used to take the current time and then set BUILD_DATE to
the first Sunday of the month (unofficial builds) or to that date at 5am
(official builds), so that the date stays constant for a while, to
keep binary hashes changing less frequently. (BUILD_DATE makes it into
base/, so most binaries contain it.)

This behavior is kept, but it's now based off the timestamp of the most
recent commit.

This has the advantage of being deterministic, so for example if some
Android bot builds the same revision twice, it's now guaranteed that
both builds will end up with the same timestamp. The motivation is that
I want to reland https://chromium-review.googlesource.com/1161104 which
broke Android bots which assume fully deterministic BUILD_DATEs and
currently only work by accident due to write_build_date_header.py not
rerunning in incremental builds.

Since querying git is slow and the timestamp will be queried at
gn gen time in a follow-up change, let lastchange.py write the last
commit's timestamp in a file next to build/util/LASTCHANGE and then read
that in write_build_date_header.py.

For official chrome builds we ship, this shouldn't make much of a difference,
since there's always recent commits when we ship those (if only to
update chrome/VERSION).

When syncing to an old revision (past the revision this change lands in, of
course -- say this lands and then 2 years pass, and then you sync back
1.5 years), that will now have an old date while it had a current date
before. This could happen while bisecting. You'd get more security
interstitials while bisecting.

Embedders might ship old Chromiums without having a recent commit
in src. These would have BUILD_DATEs in the past.  I announced this change on
https://groups.google.com/a/chromium.org/forum/#!topic/embedder-dev/Ymk3bHPQ45M
We can add an explicit opt-out if requested.

Build date currently affects:
- HSTS lists (considered valid for 70 days past build date)
-- but only enabled for official chrome builds (GOOGLE_CHROME_BUILD
   check in TransportSecurityState())
- certificate transparency (considered valid for 70 days past build date)
- invalid cert date interstitial (warns if system clock is
  more than 2 days behind build date, or more than 365 days
  in the future)
- browser upgrade detector indicator UI (stops checking after
  build is 12 weeks old)
- field trials (kNoExpirationYear is 2 years past build date)

//base:build_date already depends on lastchange_file and only reruns
when that file is touched (and on full builds).

Lots of prior discussion in https://codereview.chromium.org/1641413002/
(this approach but without widening was suggested in comment 26,
comment 46 mentions security concerns from agl, comment 67 onwards are about
security too. Eventually http://crbug.com/584880 got filed with a plan similar
to this CL here, but there was no time to evaluate the proposal at the time
due to internship schedule reasons. I talked to security -- namely,
felt agl ncarter carlosil -- and everyone thinks this has no obvious issues.)

Obsoletes https://chromium-review.googlesource.com/c/564598/, a prior attempt
at getting deterministic builds (opt-in, by setting an env var with the desired
date).

Bug: 314403,584880,871173
Change-Id: I6ccd78bff005572a9fa391e9820f4f5f83583c50
Reviewed-on: https://chromium-review.googlesource.com/1167913
Reviewed-by: Alex Mineer <amineer@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583420}