OpenSSL: no "legacy" provider

Sat Feb 7 08:15:50 PST 2026

Hi,

I have created an issue here: https://github.com/DragonFlyBSD/DeltaPorts/issues/1525

It requests the addition of option LEGACY to all openssl DPorts.

Concerning LibreSSL in the core OS, it is something that will need to be changed at some point.
LibreSSL was forked from OpenSSL at a time when the latter was buggy, vulnerable, and poorly
maintained. The other alternative was to fix OpenSSL, restart with new maintainers and funds.
The creators of LibreSSL had bet that this was not possible and LibreSSL would be the future.
10-15 years later, it is clear that they lost their bet. OpenSSL is now more active than ever.
It receives new features, API enhancements, speed optimization through specialized assembly
code, post-quantum and hybridation features, etc. LibreSSL lags way behind and seems to have
lost the race. OS using it in their core only make porting of modern applications more difficult.

As an example, after developing my project on Linux and macOS, porting to FreeBSD and NetBSD
was straightforward, as far as OpenSSL is concerned. Just because OpenSSL is in the core OS.
On the other hand, porting to OpenBSD and DragonFlyBSD is a pain because of LibreSSL in the
core OS and multiple versions of (incomplete) OpenSSL in the package manager. The situation
is even worse on OpenBSD where some libraries such as libcurl are built with the core LibreSSL,
interfering with OpenSSL in applications which use both (application crash).

As a conclusion, LibreSSL was a nice idea 10 years ago but now it is just a source of trouble.
It does not bring any advantage. As disappointing as it can be, it would simply be better to
get rid of it everywhere.

-Thierry Lelégard (mailto:thierry at lelegard.fr)

From: Justin Sherrill <justin at shiningsilence.com> 
Sent: Saturday, 7 February, 2026 01:15
To: thierry at lelegard.fr
Cc: Pierre-Alain TORET <pierre-alain at toret.fr>; users <users at lists.dragonflybsd.org>
Subject: Re: OpenSSL: no "legacy" provider

This seems like something that could justify a bugfix release. I am not qualified to swap out LibreSSL but I will roll a new release if someone else can upgrade to OpenSSL (and include options that would help Thierry)

On Fri, Feb 6, 2026 at 6:44 PM <mailto:thierry at lelegard.fr> wrote:
Hi Pierre-Alain,

OK, I start to understand. Forgive my ignorance on DragonFly BSD. The repo DragonFlyBSD/DeltaPorts
only contains the differences with FreeBSD Ports. Am I right?

So, the core problem is that OpenSSL is the default on FreeBSD, installed in the core OS, outside
Ports, with a decently recent version and all providers, including the legacy provider, while DragonFly
uses an obsolete and incompatible LibreSSL in the core OS, forcing us to install OpenSSL Port, which
is otherwise useless on FreeBSD.

So, adding LEGACY to security/openssl can be a bug request to DragonFlyBSD/DeltaPorts, to be
added in the differences. However, boosting openssl to a more recent version is more risky
because its impacts on that port may be too high. There are separate version-specific ports
for openssl33, 34, 35, 36. So, the solution is probably to request the same update on all of
them, don't change the baseline of openssl port, and install a more recent version if necessary.

I don't have any account on https://bugs.dragonflybsd.org. I will create an issue on GitHub.

Thank you for your help.

-Thierry Lelégard (mailto:thierry at lelegard.fr)

-----Original Message-----
From: Pierre-Alain TORET <mailto:pierre-alain at toret.fr> 
Sent: Friday, 6 February, 2026 18:45
To: Thierry Lelégard <mailto:thierry at lelegard.fr>; users <mailto:users at lists.dragonflybsd.org>
Subject: Re: OpenSSL: no "legacy" provider

Thierry,

we're inheriting most of the options (and ports) we use from FreeBSD ports.

I just checked, LEGACY option is disabled in their ports tree
https://cgit.freebsd.org/ports/tree/security/openssl/Makefile#n43

But your port uses the base SSL of FreeBSD, which is different from the one in DragonFly (LibreSSL, not up-to-date). So we will see how to adapt so that the port can build properly.

Can you please open an issue in either https://bugs.dragonflybsd.org or in https://github.com/DragonFlyBSD/DeltaPorts about that ?

Le 06/02/2026 à 16:30, Thierry Lelégard a écrit :
> Hi Pierre-Alain,
> 
> Thanks for your response. It clearly explains the problem.
> 
> The choice of building the openssl package with the FIPS module but 
> not the LEGACY one is quite unfortunate. It makes the openssl package 
> incompatible with all other operating systems, where the "legacy" 
> provider is always available by default.
> 
> Rebuilding openssl is of course possible but that is probably not what 
> a user would expect to do. If I would like to add tsduck (my
> project) to DragonFly's DPort (it has been recently added to FreeBSD 
> Ports), it would require openssl as a dependency. However, that 
> openssl package does not meet the requirement for the "legacy" package.
> And therefore, tsduck cannot be added to DPort.
> 
> Do you think that there is any chance to have openssl rebuilt with the 
> "legacy" provider enabled by default? And also maybe a decently more 
> recent version? The current OpenSSL project is at version 3.6. Version 
> 3.0 is outdated.
> 
> I understand that this is too demanding for my project. But any other 
> application requiring legacy cryptographic algorithms would face the 
> same problem. So, this is a more general issue.
> 
> Of course, the term "legacy" is not appealing. However, some 
> applications need this module. It contains old cryptographic 
> algorithms which are no longer considered secure enough. They should 
> not be used in new applications. This is why OpenSSL moved them in a "legacy"
> provider. They are no longer usable by default. The application must 
> explicitly activate that provider to use them, making it clear that 
> this is legacy stuff. But applications working on old data or old 
> protocols (such as ATSC TV streams in the case of
> tsduck) need them. So having the legacy provider available on demand 
> is a requirement for these applications.
> 
> -Thierry Lelégard  (mailto:thierry at lelegard.fr)
> 
> -----Original Message-----
> From: Pierre-Alain <mailto:pierre-alain at toret.fr>
> To: John <mailto:dragonflybsd at marino.st>; Thierry <mailto:thierry at lelegard.fr>
> Cc: users <mailto:users at lists.dragonflybsd.org>
> Date: Friday, 6 February 2026 3:42 PM CET
> Subject: Re: OpenSSL: no "legacy" provider
> 
> 
> Hi Thierry,
> 
> concerning DPorts, there is the LEGACY option available :
> 
> https://gitweb.dragonflybsd.org/?p=dports.git;a=blob;f=security/openss
> l/Makefile;h=13d4729473fec2601acac1aaa9bd81526b70946b;hb=HEAD#l71
> 
> But if you look at the line defining OPTIONS_DEFAULT, it's disabled. 
> So you would need to rebuild the package with that LEGACY option 
> enabled to get the legacy provider module built-in.
> 
> It's building fine on current master.
> 
> Le 06/02/2026 à 15:03, John Marino (DragonFly) a écrit :
>> So between FreeBSD and NetBSD you are mixing up your SSL sources.  
>> You quoted the base SSL on FreeBSD and you quoted the pkgsrc version of openssl.
>>
>> So I assume you are looking at the base SSL of DragonFly which is 
>> actually an older libreSSL.
>>
>> What you should be looking at is the dports or Ravenports version of 
>> openssl 3.0, because you would be linking with those, not the base 
>> SSL library.
>>
>> For ravenports, openssl3 does indeed install a legacy.so.
>> https://www.ravenports.com/catalog/bucket_B9/openssl30/std/ <https:// 
>> http://www.ravenports.com/catalog/bucket_B9/openssl30/std/>
>> https://raw.githubusercontent.com/Ravenports/Ravenports/master/
>> bucket_B9/openssl30 <https://raw.githubusercontent.com/Ravenports/
>> Ravenports/master/bucket_B9/openssl30>
>>
>> John
>>
>>
>> On Fri, Feb 6, 2026 at 7:58 AM Thierry Lelégard <mailto:thierry at lelegard.fr 
>> <mailto:mailto:thierry at lelegard.fr>> wrote:
>>
>>      Hi,
>>
>>      I maintain an open source project (http://tsduck.io <http://tsduck.io>)
>>      which uses OpenSSL as cryptographic
>>      library. For some old format, DES is used. No need to comment why
>>      DES shall no
>>      longer be used, it's for management of old data only.
>>
>>      With OpenSSL, DES is now part of the "legacy" provider module. The
>>      provider must
>>      be explicitly activated in the application.
>>
>>      On FreeBSD 15.0 with OpenSSL 3.5.4, the legacy provider module is in
>>      /usr/lib/ossl-modules/legacy.so.
>>
>>      On NetBSD 9.3 with OpenSSL 3.6.0, it is in /usr/pkg/lib/ossl-
>>      modules/legacy.so.
>>
>>      However, on DragonFly BSD 6.4.2 with OpenSSL 3.0.15, there is no
>>      "legacy" module.
>>      The only SSL module is the "fips" one in /usr/local/lib/ossl-
>>      modules/fips.so.
>>      And of course, all DES operations fail.
>>
>>      It is not a matter of OpenSSL version, the principle of "providers"
>>      was introduced
>>      in 3.0 and the legacy provider was created to host old algorithms.
>>
>>      Is there a "legacy" OpenSSL module with DragonFly BSD or was it
>>      completely removed
>>      from the OpenSSL package? I found no additional package which could
>>      install it.
>>
>>      Thanks for your help.
>>
>>      -Thierry Lelégard  (mailto:thierry at lelegard.fr 
>> <mailto:mailto:thierry at lelegard.fr>)
>>
> 