Kurt Roeckx writes:
> So as one of the OpenSSL people, it seems unrealistic to even have
> a compile time option to remove MD5 and SHA-1 at this time. Both
> are needed for TLS 1.0. It seems unrealistic that we can drop
> support for that in the next 5 years. We still support SSLv3, but
> it's disa
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 t
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.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
Yo Matthew!
On Fri, 27 Jan 2017 21:19:55 -0500
Matthew Selsky wrote:
> > I can only find SHA1 in ntpsec. what am I missing?
> See NID_sha in tests/libntp/ssl_init.c
I just removed a bunch of unused SSL stuff. There is still a ton
of tests for things ntpd never does.
I see no other use of N
On Fri, Jan 27, 2017 at 05:20:48PM -0800, Gary E. Miller wrote:
> 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?
H
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
-
On Fri, Jan 27, 2017 at 03:57:36PM -0500, Daniel Franke wrote:
> 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 G
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 can't easily search to fin
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 local copies when I get bac
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 them either. I don't think
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 search to
> find
> out right now). Somebod
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 not an area in which I
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 Op
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 of this thicket.
>
> Here are our constraint
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 no grounds to even argue w
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 optional.
So why does openssl need to
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.
--
http://www.catb.org/~esr/";>Eric S. Raymond
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. 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 mess, using non standard lib
On 1/27/17, Mark Atwood wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
WolfSSL is full GPLv2 with no or-any-lrater-version provision. Are you
comfortable with having a dependency licensed under those terms?
Possibly more importantly, Wolf
If we are going to have an SSL dependency, I have a pretty strong
preference towards WolfSSL
if we are going to have an OpenSSL dependency, it needs to be to the latest
stable OpenSSL release.
What would be using an SSL library for, that libsodium does not already
provide?
What all are we using
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 repeated references to "SHA and SHA-1". I don't
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 repeated references to "SHA and SHA-1". I don't see how that
could reasonablt
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 whic
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 unconditionally.
>
> https://do
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 out to be a no-op - I thi
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 m
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 rid of --enable-crypto
Ye
[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 I
29 matches
Mail list logo
