Current status of --enable-crypto

[Eric S. Raymond]

Mark: Heads up!  PR issue.

Matthew Selsky <Matthew.Selsky at twosigma.com>:
> 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 mean sha0 or sha1?

>From context, SHA-0 - supported only if OpenSSL is linked.  I have
disambiguated in the documentation.

> OpenSSL/LibreSSL's libcrypto is only needed for ntp.keys that are using a digest> that's neither MD5 nor SHA1.
>
> As 2 data points (yes, not enough), my users are using MD5
> internally.  I also spoke to Dr Levine from NIST yesterday and of
> his 500 customers that use authentication, all but 2 use MD5.  The
> other 2 customers use SHA1.  None of his customers use anything
> fancier.

That's kind of interesting. To me it suggests that maybe we should drop OpenSSL
and support for MAC types other than ND5 and SHA-1.  I can see that we might
want to keep the others for PR reasons, though, even if they haven't got
actual traction.

Mark: do you have an opinion about this?

> Can we make OpenSSL an optional dependency?

Hm.  I thought it was already optional.  But INSTALL says differently, and
mow I'm not sure.  Checking...

OK, I was right and INSTALL is wrong.  waf has openssl marked optional.

>I'd prefer that we always use the public domain code for MD5 and
>SHA1 and then use the OpenSSL code when available, but only for
>digest algorithms that are exclusive to them?  That will allow us to
>have few #ifdef branches and be better able to test the code. And
>there's no need to add an extra build requirement when most users
>won't need it.

I have a higher-priority thing to chew on (nuking interface scanning) but
I'd take that patch from you.  It's good cleanup even if we then decide to drop
OpenSSL entirely.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>