curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Incoming DES headache with OpenSSL 3

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 24 Mar 2020 17:31:49 +0100 (CET)

On Tue, 24 Mar 2020, Kamil Dudka wrote:

>> A) Live with (and work around) the compiler warnings as long as we can link
>> fine. (We don't know for how long that'll work.)
>>
>> B) Disable NTLM when OpenSSL version 3 or later is used
>>
>> C) Import DES code (as we have done for MD4 and MD5) and build with that
>> code when OpenSSLv3 is used.
>>
>> D) Use another 3rd party DES lib (which?) when OpenSSLv3 is used.
>>
>> E) Other: ________
>>
>> I think I personally am in the C or D camp for the moment.
>>
>> Thoughts?
>
> Option C is going to cause a disaster while importing such code to enterprise
> OS distributions because of export control and FIPS-like certifications. Let
> me first ask internally what a preferred choice for Red Hat would be...

Thanks. That's useful feedback.

I'm right now experimenting with option (A) and adding
-Wno-deprecated-declarations to the compiler options to avoid the deprecation
warnings with OpenSSL v3. It might be worth it as a first shot...

I forgot to mention it before, but my current PR for these OpenSSLv3
adjustments are here: https://github.com/curl/curl/pull/5139

--
  / daniel.haxx.se | Commercial curl support up to 24x7 is available!
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2020-03-24