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. 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