Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc

On 5/3/23 4:02 PM, Pierre Pronchery wrote:
> 		Hi everyone,
> 
> On 5/2/23 23:24, John Baldwin wrote:
>> On 5/2/23 2:59 AM, Antoine Brodin wrote:
>>> On Tue, May 2, 2023 at 1:55 AM Enji Cooper <yaneurabeya@gmail.com> wrote:
>>>>
>>>> Hello,
>>>> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL
>>>> 3.0 into the base system. This is a must because, in short, OpenSSL
>>>> 1.1 is no longer supported as of 09/26/2023 [1].
>>>>
>>>> I am proposing OpenSSL be made private along with all dependent
>>>> libraries, for the following reasons:
>>>> 1. More than a handful of core ports, e.g., security/py-cryptography
>>>> [2] [3], still do not support OpenSSL 3.0.
>>>> i. If other dependent ports (like lang/python38, etc) move to OpenSSL
>>>> 3, the distributed modules would break on load due to clashing
>>>> symbols if the right mix of modules were dlopen’ed in a specific
>>>> order (importing ssl, then importing hazmat’s crypto would fail).
>>>> ii. Such ports should be deprecated/marked broken as I’ve recommended
>>>> on the 3.0 exp-run PR [4].
>>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in
>>>> both libraries at runtime impossible without resorting to a number of
>>>> linker tricks hiding the namespaces using symbol prefixing of public
>>>> symbols, etc.
>>>>
>>>> The libraries which would need to be made private are as follows:
>>>> - kerberos
>>>> - libarchive
>>>> - libbsnmp
>>>> - libfetch [5]
>>>> - libgeli
>>>> - libldns
>>>> - libmp
>>>> - libradius
>>>> - libunbound
>>>
>>> In my opinion this is a huge amount of work a few weeks before the
>>> release.  Focusing on updating OpenSSL and those core ports may be
>>> simpler.
>>
>> This is my view.  I think making OpenSSL private is a very huge task, and
>> fraught with peril in ways that haven't been thought about yet (e.g. PAM)
>> and that we can't hold up OpenSSL 3 while we wait for this.  Instead, I
>> think
>> we need to be moving forward with OpenSSL 3 in base as-is.  We will have to
>> fix ports to work with OpenSSL 3 regardless (though this does make that
>> pain
>> in ports happen sooner).  Moving libraries private can happen orthogonally
>> with getting base to work with OpensSL 3.
> 
> I have started to look at updating OpenSSL to version 3.0.8 in base,
> using the existing vendor/openssl-3.0 branch.
> 
> My progress can be found at
> https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I
> regularly force-push to keep a consistent and nice commit history,
> before possibly applying for a merge.
> 
> So far the status is:
> 
> - libssl, libcrypto build on amd64, i386, less sure about aarch64, other
> architectures not tested
> - libfetch builds, uses libmd in addition to OpenSSL
> - libradius builds, same thing
> - libarchive builds
> - libunbound builds, but not unbound
> - libmp builds
> 
> I used libmd to reach a buildable status faster, since the equivalent
> MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in
> OpenSSL 3, we can avoid the dependency on libmd again. (anyone got
> sample code for this?)

You can use the EVP_* API if desired.  tools/cryto/cryptocheck.c has examples
of using the EVP_* APIs for both "plain" hashes and HMAC constructions

-- 
John Baldwin