[pvg]

In what way? 'Temporal' fuzzing to an eon-like range of two seconds seems, naively at least, entirely impractical.

Edit: a somewhat different way of putting this concretely - what is a practical stochastic testing regime that can reasonably be expected to find this bug?

[londons_explore]

Well designed systems have a mockable clock and timer subsystem.

They could easily test "Do X, wait 100 years, do Y".

You find all kinds of wired bugs when you do that - things that poll, for example Cron daily, will have to be run 36500 times. Certificates expire. Counters overflow. Date systems can't convert the date to and from strings. Logfiles get too big. Etc.

[pvg]

I guess if the answer to 'how do you fuzz time' is 'easily wait 100 years', I have no further questions.

[Bombthecat]

You know you can set the clock / time date of Systems without ntp? :)

[pvg]

The premise was that basic automated testing by some other team at Google (to whom the HSM is a black box) would catch this. I don't see how that's obvious. Then you're all 'but fuzzing!' and I'm like 'wat' and now you're asking me if I know you can set the clock on the HSM? I don't think I know that. It's a black box.