Bug 2066257 - clamp absurd logins timestamps

[jo]

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

[bendk]

I'd rather use the server time if we could, since local clocks can have all kinds of weird behavior.

I think that could be done during sync, probably right here. You could iterate through records and clamp the timestamp for local to the server timestamp. You could also do the same for mirror and inbound, although I'm not sure if that's needed.

[jo]

Thank you, Ben, for these thoughts. Looking at it again I realized the problem could be fixed way simpler - this now just resets out-of-range timestamps to 0.

[jo]

I was able to find signals of these out of range timestamps in telemetry, I added the values to the testcases.

Desktop also sets these wrong timestamps to 0: https://searchfox.org/firefox-main/source/toolkit/components/passwordmgr/LoginManager.sys.mjs#6 - I have adjusted the patch to apply the very same sanitization here.