Re: Current status of --enable-crypto

2017-01-27 Thread Greg Rubin
While I cannot speak specifically to NTP, SHA (without any suffix) has been used on other contexts to mean SHA-1. I've also never encountered SHA-0 being used in any standard. So, if NTP is actually using it and it's not just a misunderstanding, that would be a first for me. I suspect it is SHA-1

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Matthew Selsky : > Where do we get SHA-0, aka "sha", keytype support from if we remove the > in-tree public domain version? To my knowledge the only SHA we have in tree is SHA-1. I think you can only get SHA-0 via OpenSSL. --

Re: Current status of --enable-crypto

2017-01-27 Thread Gary E. Miller
Yo Matthew! On Fri, 27 Jan 2017 20:05:14 -0500 Matthew Selsky wrote: > LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the > build on OpenBSD 6.0 I can only find SHA1 in ntpsec. what am I missing? RGDS GARY

Re: Current status of --enable-crypto

2017-01-27 Thread Kurt Roeckx
On Fri, Jan 27, 2017 at 03:42:09PM -0500, Eric S. Raymond wrote: > Daniel Franke : > > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1 > > support any time soon? That's inconceivable to me. > > I think it was either Achim Gratz or Kurt Roecx (I

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Daniel Franke : > I just checked with an OpenSSL dev to make certain: dropping MD5 and > SHA1 from libcrypto is not even remotely under consideration. All right. I'm off to Friday night gaming, but given what Mark has said I'm going to take this as my cue to remove the

Re: Current status of --enable-crypto

2017-01-27 Thread Daniel Franke
On 1/27/17, Mark Atwood wrote: > Daniel, if we make OpenSSL a requirement, can we drop libsodium? Yes. > Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al) 1.0.1 and prior are no longer supported upstream so I'm not going to make any effort to support

Re: Current status of --enable-crypto

2017-01-27 Thread Daniel Franke
On 1/27/17, Eric S. Raymond wrote: > Daniel Franke : >> Where is this notion coming from that OpenSSL is going to drop MD5 or >> SHA1 >> support any time soon? That's inconceivable to me. > > I think it was either Achim Gratz or Kurt Roecx (I can't easily

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Daniel Franke : > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1 > support any time soon? That's inconceivable to me. I think it was either Achim Gratz or Kurt Roecx (I can't easily search to find out right now). Somebody serious, anyway. This is

Re: Current status of --enable-crypto

2017-01-27 Thread Mark Atwood
OpenSSL is not going to drop them anytime soon. if/when they do, we can add back inline support in better understood ways. Daniel, if we make OpenSSL a requirement, can we drop libsodium? Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al) If/when we encounter a target without

Re: Current status of --enable-crypto

2017-01-27 Thread Daniel Franke
Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1 support any time soon? That's inconceivable to me. On Jan 27, 2017 3:21 PM, "Eric S. Raymond" wrote: > Mark Atwood : > > We do need to get wacking on the weeds on removing more

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Mark Atwood : > We do need to get wacking on the weeds on removing more of this thicket. Here are our constraints: * Daniel has stated that he prefers the OpenSSL implementations of MD5 and SHA-1. He's our crypto expert, so he gets to make that call and I would have

Re: Current status of --enable-crypto

2017-01-27 Thread Gary E. Miller
Yo Eric! On Fri, 27 Jan 2017 14:42:16 -0500 "Eric S. Raymond" wrote: > Gary E. Miller : > > And, don't forget, libisc is still in the tree with its own copies > > of md5 and sha1. Nuke it! > > Er, we can't do tha id we wabt the OpenSSL deoendency to be

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Gary E. Miller : > And, don't forget, libisc is still in the tree with its own copies of > md5 and sha1. Nuke it! Er, we can't do tha id we wabt the OpenSSL deoendency to be optional. Otherwise, I'd be happy to get rid of that code. --

Re: Current status of --enable-crypto

2017-01-27 Thread Mark Atwood
WolfSSL has a "we are compatible with any OSI approved license" codecil to their license. I can get a formal signed commitment and document from the CEO reinforcing it. We do need to get wacking on the weeds on removing more of this thicket. ..m On Fri, Jan 27, 2017 at 10:38 AM Gary E.

Re: Current status of --enable-crypto

2017-01-27 Thread Gary E. Miller
Yo Mark! On Fri, 27 Jan 2017 18:14:15 + Mark Atwood wrote: > If we are going to have an SSL dependency, I have a pretty strong > preference towards WolfSSL It may be the best, but it is not in Gentoo. I suspect few distros have it. As we see from the libsodium

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Eric S. Raymond : > Daniel Franke : > > If SHA-0 has ever been used in NTP that's news to me. It was broken pretty > > quickly after publication and never saw much use. Pretty sure any > > documentation which refers to it is confused. > > There were

Re: Current status of --enable-crypto

2017-01-27 Thread Daniel Franke
If SHA-0 has ever been used in NTP that's news to me. It was broken pretty quickly after publication and never saw much use. Pretty sure any documentation which refers to it is confused. I would prefer that OpenSSL implementations of primitives get used when available, for performance reasons

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Mark: Heads up! PR issue. Matthew Selsky : > On Wed, Jan 25, 2017 at 11:47:01PM -0800, Hal Murray wrote: > > > > [From gitlab] > > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There > > > should > > > be no problem with using the ISC version

Re: Current status of --enable-crypto

2017-01-27 Thread Eric S. Raymond
Hal Murray : > > [From gitlab] > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should > > be no problem with using the ISC version unconditionally. > > I though I saw something about getting rid of --enable-crypto It's gone. It actually turned

Re: Current status of --enable-crypto

2017-01-26 Thread Matthew Selsky
On Wed, Jan 25, 2017 at 11:47:01PM -0800, Hal Murray wrote: > > [From gitlab] > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should > > be no problem with using the ISC version unconditionally. https://docs.ntpsec.org/latest/ntpq.html's keytype lists "SHA". Does that

Re: Current status of --enable-crypto

2017-01-26 Thread Gary E. Miller
Yo Hal! On Wed, 25 Jan 2017 23:47:01 -0800 Hal Murray wrote: > [From gitlab] > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. > > There should be no problem with using the ISC version > > unconditionally. > > I though I saw something about getting

Current status of --enable-crypto

2017-01-25 Thread Hal Murray
[From gitlab] > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should > be no problem with using the ISC version unconditionally. I though I saw something about getting rid of --enable-crypto We currently require libsodium. Do we require libssl? If so, we can drop the