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 23. 5. 2., Rene Ladan wrote:
> On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote:
>> On 23. 5. 1., A. Wilcox wrote:
>>> On May 1, 2023, at 8:55 PM, 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
>>>>
>>>> I realize I’m jumping to a prescribed solution without additional
>>>> discussion, but I’ve been doing offline analysis related to uplifting
>>>> code from OpenSSL 1.x to 3.x over the last several months and this is
>>>> the general prescribed solution I’ve come to which is needed for
>>>> $work. My perspective might have some blind spots and some of the
>>>> discussion done over IRC and might need to be rehashed here for
>>>> historical reference/to widen the discussion for alternate solutions
>>>> that don’t have the degree of tunnel vision which the solution I’m
>>>> employing at $work requires.
>>>> I’ve tried to include some of the previously involved parties so they
>>>> can chime in.
>>>> Thank you,
>>>> -Enji
>>>>
>>>> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
>>>> <https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/>
>>>> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853
>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853> .
>>>> 3. The reason why it hasn’t been upgraded is because newer versions
>>>> require rustc to build, which apparently doesn’t work on QEMU builders
>>>> due to missing emulation support:
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853
>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853> .
>>>> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413#c15
>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413#c15>
>>>> 5. If I remember correctly, some folks suggested that making libfetch
>>>> private wasn’t required since the only port that required it was
>>>> ports-mgmt/pkg, but I haven’t validated this claim.
>>>
>>>
>>> Hi Enji (+ arch list),
>>>
>>> My opinion may not amount to much, but I’m not sure it makes sense to
>>> make it private solely for the sake of allowing ports to keep going with
>>> known insecure software.
>>>
>>> I think ports should be loudly warning, right now, that they require
>>> OpenSSL 1.x and there should be work with both upstreams and end users
>>> to seek out and migrate to OpenSSL 3.  I, with others, have already
>>> begun this work a while back in the Linux world.
>>>
>>> If the desire is to make these libraries private for future
>>> improvements, or for the ability to swap in other another crypto/TLS
>>> implementation and perform experiments and innovate, then that seems
>>> like it could be a useful tradeoff. However, if it’s just to allow
>>> insecure software to continue to be used, I think that is ill advised.
>>>    The global landscape of information security is different and I think
>>> it warrants a different response than maybe it would have in the past.
>>>    And it should at least be a consideration to have a loud and forceful
>>> break in the interest of keeping data private and secure.
>>
>> +1
>>
>> Jung-uk Kim
> 
> (Randomly replying)
> 
> Ports upstreams will probably take their time (if ever) to migrate off
> OpenSSL 1.X, as we have seen with Python 2.7. Having a private library
> for OpenSSL in base might also simply the SSL framework in ports (?)
> 
> René (personal hat only)

Please note upgrading OpenSSL and having private library are orthogonal 
issues.  I do not disagree with the private library idea if it is 
upgraded and well maintained.  I believe sweeping security 
vulnerabilities under the rug is a recipe for disaster.

Jung-uk Kim