Richard Laager :
> On 1/21/19 2:28 PM, Eric S. Raymond via devel wrote:
> > I don't either, and I think there is no functional point in trying to cope
> > with that. So I'm going to deal with this by adding to the documentation a
> > line that says changing this flag at runtime may produce undefine
On 1/21/19 2:28 PM, Eric S. Raymond via devel wrote:
> I don't either, and I think there is no functional point in trying to cope
> with that. So I'm going to deal with this by adding to the documentation a
> line that says changing this flag at runtime may produce undefined behavior.
Is it easy t
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > I have converted ENABLE_LOCKCLOCK to a runtime option. Following a
> > review suggestion, it is controlled by flag1 of the localclock driver.
>
> With the condition bug out of the way, I have a more fundamental problem
> with the "run
Richard Laager via devel writes:
> Opportunistic NTS is only applicable when the administrator has not
> specified NTS. In that scenario, if ntpd doesn't do opportunistic NTS,
> then it's going to do plain NTP. How is the risk that a MITM could
> downgrade you only at startup worse than always bein
On 1/21/19 11:14 AM, Achim Gratz via devel wrote:
>> If the user has asked for NTS, obviously a downgrade should not be
>> allowed. But if the user has not asked for NTS, they're going to get
>> plain NTP anyway. There is no security harm in trying to upgrade it.
>> Other than potentially the fact
Eric S. Raymond via devel writes:
> I have converted ENABLE_LOCKCLOCK to a runtime option. Following a
> review suggestion, it is controlled by flag1 of the localclock driver.
With the condition bug out of the way, I have a more fundamental problem
with the "runtime" part of that patch.
In princi
James Browning via devel writes:
> Not seeing a viable exploit ATM. One would need to get a server in the
> pool, a ridiculous amount of computer power and/or an exploit against AES
> and/or ChaCha as well as acesss to the packet stream of a given host which
> puts it out of the range of almost any
On Mon, Jan 21, 2019, 9:20 AM Achim Gratz via devel Hal Murray via devel writes:
> >> My thought about how to enable NTS for the pool would involve requiring
> a SRV
> >> record lookup for NTS-KE
> >
> > That SRV lookup could return multiple names. Each would point to a
> separate
> > NTS-KE serv
Hal Murray via devel writes:
>> My thought about how to enable NTS for the pool would involve requiring a SRV
>> record lookup for NTS-KE
>
> That SRV lookup could return multiple names. Each would point to a separate
> NTS-KE server.
>
> An alternative approach would be to extend the NTS-KE prot
Richard Laager via devel writes:
> On 1/20/19 1:34 PM, Achim Gratz via devel wrote:
>> Richard Laager via devel writes:
> * Is NTPsec going to initiate NTS by default?
>>>
Probably not. That would break backward compatibility.
>>
>> The draft RFC states that falling back to plain NTP fr
Richard Laager via devel writes:
> On 1/19/19 6:30 PM, Hal Murray wrote:
>> We can avoid sharing the master key with many NTP servers if the NTS-KE
>> server
>> contacts the selected NTP server to get the initial cookies.
The other (and probably better) solution is to establish a different maste
Hal Murray via devel writes:
> A likely candidate is a call to loop_config()
Yes, I think you've got the bug there. I'll still have to watch the
statistics to see if there's something else amiss, but for the short
while I've run with the new code it looks like that fixes things.
Regards,
Achim.
Hal Murray via devel writes:
> Maybe Achim can give you the recipe and you can reproduce a test case and
> graph some of the statistics and see the difference.
The recipe is very simple, just fire up a config without a local clock,
but instead a GPS or similar refclock. The frequency offset shou
Udo van den Heuvel via devel :
> On 21-01-19 03:20, Hal Murray via devel wrote:
> > So my guess is that the normal path isn't putting the right stuff into the
> > kernel. We are missing a call to ntp_adjtime
>
> A fresh build of latest git shows me, straight after ntpd restart:
>
> # /usr/bin/n
Hal Murray :
> I just pushed a fix - removing the !.
Heh. I was pretty sure the bug was going to turn out to be a negated
guard element somewhere.
Here's hoping you found the right one. That section of code is hard
to reason about.
--
http://www.catb.org/~esr/";>Eric S. Raymond
15 matches
Mail list logo
