Re: [gentoo-dev] Signed push & clock drift rejection

[Andrew Savchenko]

Hi,

On Fri, 15 Jul 2016 18:03:30 +0000 Robin H. Johnson wrote:
> Hi all,
>
> In tracing down problems with the git->rsync path, it has been noticed
> that some developers have significant clock drift on their local systems
> (up to one case of 14 days wrong), and it's potentially contributing to
> problems in generating the rsync tree.
>
> I have implemented a check as part of the hook that validates Git push
> certificates (require-signed-push). It looks for clock drift or an
> overly long push, and aborts if needed.
>
> The tolerances are presently set to:
> - 5 seconds of clock drift.

Why such tight requirement? Why not a minute, which will not hurt
git, but will help with system _temporarily_ out-of-sync.

Some hardware clocks are real mess and can drift more that for 5
seconds in a few days (e.g. when system was shut down). And for NTP
it will take time to correct system clock _properly_. While stuff
like running ntpdate before ntp server if system is out of sync is
possible, but it is not recommended nor possible on some workloads.
So IRL NTP may take several hours to sync system properly.

Set it for a minute or two. This will protect from commits from
really out-of-sync systems (like 14 days mentioned above) and will
keep usablity hight for others.

> - 'git push' must be completed in 60 seconds.

Why?! What is wrong if push will take 120 seconds? I often commit
from quite an old box and git push takes 20-40 seconds, while this
is within your limits, the margin is not safe.

What if someone needs to commit via 2G GPRS or similar slow network
link? Afaik we have developers on quite slow and unstable links.

Just set this limit to 5 minutes to make it a sane protection of a
stale push.

Best regards,
Andrew Savchenko