Status, the login prompt and the launcher say when the clock reads more than a day before the newest statement, which would refuse every newer one

[DevomB]

What was wrong (3a's whole-picture read, LOW 1)

A clock behind the newest accepted statement silenced the 30-day report, and every newer statement was then refused without anyone being told.

• staleness (update.rs:149-152) counts a clock behind issued as zero days. stale_line said nothing, and status said "stated 0 day(s) ago".
• Each newer statement is refused as "dated more than a day after this machine's clock" (update.rs:137-139). That reply goes only to the net zone (broker.rs:242-245).
• The same holds before any statement, against the install record.

Two ways a clock gets there:

• A dead RTC starts at the floor (time.rs:247-255): the build date or the committed release, both earlier than a statement the channel re-signs daily. If the user then misses or declines the clock question, updates stop with nothing said.
• A net zone can offer a time weeks back but above the floor, one question every 10 minutes, until someone agrees.

update-channel.md said the report "needs a clock the net zone cannot set", which stops being true after one consent.

What changed

• update.rs:
  • While the clock reads more than a day (MAX_AHEAD_SECS) before the newest accepted statement, or, with none, before the install, stale_line says "no statement from the release key can be accepted while this machine's clock reads N days before the newest one it accepted: set the clock" ("... before its install: ..." for the second).
  • status prints that line and gives the statement as "dated N day(s) after this machine's clock" in place of "stated 0 day(s) ago".
  • The login notice is stale_line's, so it says it too. The launcher shows any status line that starts "no statement from the release key", so it does as well, with no change to the chrome.
  • Every other case prints what it did before. status now takes its indented line from stale_line for both the statement and the install.
• The design and the user guide say it. The design's tests list says what the update suite moves the clock for.

Not done: the statement as a floor, 3a's stronger option. docs/design/time.md rejects it: the statement key is online, and a stolen one could walk the clock forward a day at a time.

How the run proves it

• a_clock_behind_the_newest_is_said (update/tests.rs):

  • a clock five days before the install gives the install line, and one a day before gives nothing;
  • a clock three days before an accepted statement gives the statement line, in stale_line, in status and in the login notice;
  • set right, the notice goes.

  On the old code stale_line returns None for all of these.

• The update suite's network step (update-test.sh) is now longer. After the aged-statement checks it moves the guest's clock 3 days back and restarts the launch service. Then it needs:

  1. the login notice naming the clock's lag (BEHIND-OK);
  2. kryptik update status saying the same;
  3. the notice gone once the clock is put back (SET-RIGHT-OK).

  On the old code no notice comes, and the drive fails at BEHIND-OK.

CI's compartment job runs the unit test, and a Distro run follows on this head.

After 3a's read of 7a5dd4d (clear, three INFOs):

• A lag between one and two days now reads "1 day", not "1 days" (6864f2d). The suite's greps take either.
• The install branch counts from install.json's mtime, which is the medium's clock and is not signed. A machine installed with its RTC set days ahead, whose clock is later put right, is told to set the clock until its first statement is accepted. That is kept as a limit. The common case this branch catches is a dead RTC: it starts at the floor, which is the build date and so before the install, and then refuses every statement, with nothing said.
• The suite's 3 days back assumes a statement signed in the same run, as stage 06's channel is. The +31/-31 day steps before it already assume the same.