| Summary: | net-misc/ntp-4.2.4_p7: offset code is broken | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robin Johnson <robbat2> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | critical | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
20090620_isohunt-ntp_offset-week.png
20090620_isohunt-ntp_offset-day.png |
||
|
Description
Robin Johnson
2009-06-20 23:03:18 UTC
Created attachment 195308 [details]
20090620_isohunt-ntp_offset-week.png
the 17th is when the upgrade to _p7 was put into place, almost immediately thereafter the offset value goes huge, and does not come down.
Created attachment 195310 [details]
20090620_isohunt-ntp_offset-day.png
At the very end of the graph (the last hour), I put _p6 back onto the machine, with the MOD_NANO patch backported, and the offset value drops close to zero again.
Oh, and it's not box specific, I had this on 13 machines in my network (that were all upgraded on the 17th). ~90 minutes after going back to _p6, all boxes are back within 10ms of the same time (we need accuracy to <10ms for log correlation). With _p6, we get that <10ms, with _p7 we only get <200ms. p7 wasnt moved to stable just for the nano issue. it also has CVE issues associated with it. Yup, i'm aware of the CVE, but the offset regression is pretty major for me. Is the patch against p5 on the CVE bug all that's needed to be safe against the exploit? If so, I'll make a revbump of p6 with it in the meantime, so that we have functional+secure. i remember multiple CVEs being filed in bugzilla and rather than patch things, we simply updated to p7 you can try 4.2.6 which is in the tree now |