e...@thyrsus.com said:
[context is cleaning up crypto code]
> Oh dear Goddess you are right. I think I noticed that before but spaced it.
> I'll fix that up once I've had some sleep.
My straw man is that the table that holds keys has
password
password length
digest length
the magic that
e...@thyrsus.com said:
> Well, that's disturbing. But hard to act on until we get a better idea
> what's busted
Sorry if I wasn't clear. It's the kernel, not our code.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.o
Hal Murray :
> There shouldn't be any MD5 code. Both MD5 and SHA1 should use a generic
> routing to calculate the digest.
They both do, now that everyting goes through OpenSSL. What I meant by the MD5
code was the calls in a_md5encrypt.c, as opposed to the ones in ntp_leapsec.c.
> I copied som
Hal Murray :
>
> Both Linux (Debian) and FreeBSD have the same problem.
>
> The symptom is that the drift goes to 500 PPM and that isn't enough so every
> few minutes it steps the clock.
>
> 29 Jan 18:12:01 ntpd[568]: 0.0.0.0 c61c 0c clock_step +0.623666 s
> 29 Jan 18:17:13 ntpd[568]: 0.0.0.0 c
Heads up, Mark! Policy question.
I'd also like to hear Hal's opinion.
In the wake of the dumbclock removal, I'm now wondering if
it makes any sense at all to retain refclocks that report
only in-band time to a precision of a second. That is,
without 1PPS.
The truetime driver is that bad. You g
e...@thyrsus.com said:
> Please commit it, then.
There are two issues tangled up in this area.
Build fails on Debian sid (#237)
https://gitlab.com/NTPsec/ntpsec/issues/237
Debian sid has openssl 1.1.0c
OpenSSL v1.1 compatibility (!306)
https://gitlab.com/NTPsec/ntpsec/merge_requests/306
I
Both Linux (Debian) and FreeBSD have the same problem.
The symptom is that the drift goes to 500 PPM and that isn't enough so every
few minutes it steps the clock.
29 Jan 18:12:01 ntpd[568]: 0.0.0.0 c61c 0c clock_step +0.623666 s
29 Jan 18:17:13 ntpd[568]: 0.0.0.0 c61c 0c clock_step +0.636564 s
Hal Murray :
> What tools are available for figuring out where the cycles are going?
>
> I'd like to understand how fast ntpd does and/or can go.
I can't think of any reason plain old gprof wouldn't work for this.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
My inclination is that when more clock types show up, they get a driver
running in it's own process space, and exporting a SHM buffer.
The problem with covering existing drivers to that is... testing them.
..m
On Sun, Jan 29, 2017 at 10:49 PM Eric S. Raymond wrote:
> Hal Murray :
> > It's not
Hal Murray :
> It's not clear that there is any good way to have a starting point reference.
> If you give examples of all the possibilities, it will be too complicated.
> You can start with an existing driver. That's easy if you already know your
> way around, but there is likely to be a lot
What tools are available for figuring out where the cycles are going?
I'd like to understand how fast ntpd does and/or can go.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/
On Mon, Jan 30, 2017 at 9:15 AM, Hal Murray wrote:
> How can I be sure that it has "been seeded with enough"?
Why would OpenSSL lie? :-)
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
___
devel mailing list
devel@ntpsec.org
http:
fallenpega...@gmail.com said:
> Is there a reason to keep dumbclock? Maybe it exists as a starting
> framework for when someone wants to write a new clockdriver?
It's not good for much more.
It's not clear that there is any good way to have a starting point reference.
If you give examples o
Mark Atwood :
> Kill it
Will do.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Kill it
On Sun, Jan 29, 2017 at 9:05 PM Eric S. Raymond wrote:
> Mark Atwood :
> > Is there a reason to keep dumbclock? Maybe it exists as a starting
> > framework for when someone wants to write a new clockdriver?
>
> Actually, I only left dumbclock in because you said "keep it for the lulz"
copyright lengths will always be increased to keep Steamboat Willy under
copyright.
Right now our standard copyright text is "Copyright
$YEAR_YOU_ARE_WRITING_THIS by the NTP Project contributors"
After 50ish years goes by from now-ish, we can revisit.
..m
On Sun, Jan 29, 2017 at 1:02 PM Gary E.
Mark Atwood :
> Is there a reason to keep dumbclock? Maybe it exists as a starting
> framework for when someone wants to write a new clockdriver?
Actually, I only left dumbclock in because you said "keep it for the lulz"
during the conversation about some other refclock that we ended up dropping
I wonder if we should just start recommending that people plug one of Keith
Packard's ChaosKey's into a USB port on their NTP boxes.
https://keithp.com/blogs/chaoskey/
I just leave one plugged into my main working NUC all the time.
..m
On Sun, Jan 29, 2017 at 5:15 PM Hal Murray wrote:
>
> g..
Is there a reason to keep dumbclock? Maybe it exists as a starting
framework for when someone wants to write a new clockdriver?
..m
On Sun, Jan 29, 2017 at 5:36 AM Eric S. Raymond wrote:
> Here are the full current stats:
>
> all71320 (100.00%) in 298 files
> c 60694
g...@rellim.com said:
> You can't run out of randomness with RAND_bytes().
Would you please say more. The man page says:
RAND_bytes() puts num cryptographically strong pseudo-random bytes into
buf. An error occurs if the PRNG has not been seeded with enough
randomness to en
On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote:
> Mind running the timings with the legacy interfaces as well? We may
> determine that the speed benefits are outweighed by the risks and
> complexities of an older API, but it would be good to have the data so we
> can make an informed d
Yo Hal!
On Sat, 28 Jan 2017 23:19:32 -0800
Hal Murray wrote:
> g...@rellim.com said:
> > rand() and RAND_pseudo_rand() are not random, just psuedo random,
> > thus not for NTP.
>
> Do you think fuzzing needs cryptographically strong randomness?
You are asking the wrong guy. I'm not sure we
Mind running the timings with the legacy interfaces as well? We may
determine that the speed benefits are outweighed by the risks and
complexities of an older API, but it would be good to have the data so we
can make an informed decision.
https://www.openssl.org/docs/man1.0.2/crypto/md5.html
http
Yo Achim!
On Sun, 29 Jan 2017 21:55:31 +0100
Achim Gratz wrote:
> Gary E. Miller writes:
> > I find that running at the hightest speed, and using ther
> > performance governor leads to the best results.
>
> However, if the system is crashing due to it getting too hot or
> pulling too much cur
Yo Mark!
On Sun, 29 Jan 2017 07:58:24 +
Mark Atwood wrote:
> > Do they need to be updated? I just noticed one that was 2015.
> they don't require updating
US Copyright is now generally 70 years after the death of the author.
You plan to live that long?
RGDS
GARY
Gary E. Miller writes:
> I find that running at the hightest speed, and using ther performance
> governor leads to the best results.
However, if the system is crashing due to it getting too hot or pulling
too much current from a slightly underspeced PSU, then that slight
performance improvement is
Yo Achim!
On Sun, 29 Jan 2017 19:50:42 +0100
Achim Gratz wrote:
Looks good, except for this:
+If you want to run the system constantly at the lowest frequency
+instead (maybe to avoid thermal problems) you can use the governor
+"conservative". Everything will run slower than with governor
+"pe
Achim Gratz writes:
> Eric S. Raymond writes:
>> I'd take a patch to fix this.
>
> Can do if you tell me where's the source repository.
Nevermind, I found it.
>From 71af21049fcc58711c55a815e4028a11a75a4929 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Sun, 29 Jan 2017 19:46:42 +0100
Subject:
Eric S. Raymond writes:
> I'd take a patch to fix this.
Can do if you tell me where's the source repository.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Achim Gratz :
>
> The Stratum-1 HOWTO needlessly confuses tickless operation with the
> opposite: "An optimization that is convenient to apply at this point is
> telling the kernel to run tickless[…]". The standard kernel is running
> tickless by default and switches off the scheduling tick when
Hal Murray :
> The speedup applies to any type of crypto. I didn't bother implementing the
> MD5 half. The change is just cleaning up the per-digest initialization.
> We'll want it for anything going forward.
Please commit it, then. And please do the MD5 code in libntp/a_md5encrypt.c
and lib
The Stratum-1 HOWTO needlessly confuses tickless operation with the
opposite: "An optimization that is convenient to apply at this point is
telling the kernel to run tickless[…]". The standard kernel is running
tickless by default and switches off the scheduling tick when all CPU
become idle. Th
e...@thyrsus.com said:
> I'm not sure we care a lot about this performance gain, given that SHA-1 use
> seems to be uncommon. But the change seems simple enough and would only need
> to be done in two places. Would it change the floor version of OpenSSL we
> can use?
The speedup applies to any t
Here are the full current stats:
all71320 (100.00%) in 298 files
c 60694 (85.10%) in 152 files
python 7472 (10.48%) in 48 files
shell 1444 (2.02%) in 7 files
yacc1255 (1.76%) in 1 files
waf 455 (0.64%) in 11 files
We're down to
Hal Murray :
>
> This is computing the digest for a password and a 48 byte packet, then
> dropping it on the floor.
>
> The "old" version uses EVP_DigestInit, like the current code in ntpd.
> The new version uses EVP_DigestInit_ex and a static context.
>
>
> Intel(R) Core(TM) i3-2120 CPU @ 3.3
Hal Murray :
> > What about the OpenSSL RAND_bytes()?
>
> It's slightly faster than RAND_pseudo_bytes() :) ??
And what we're now using. I finished the cleanup last night; everything
goes through OpenSSL now, the local MD5 and SHA-1 code is gone, and the
depenendency on libsodium has been abol
This is computing the digest for a password and a 48 byte packet, then
dropping it on the floor.
The "old" version uses EVP_DigestInit, like the current code in ntpd.
The new version uses EVP_DigestInit_ex and a static context.
Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
100 MD5 encrypts took
37 matches
Mail list logo
