OpenSSL: no "legacy" provider

Fri Feb 6 15:43:58 PST 2026

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 (thierry at lelegard.fr)

-----Original Message-----
From: Pierre-Alain TORET <pierre-alain at toret.fr> 
Sent: Friday, 6 February, 2026 18:45
To: Thierry Lelégard <thierry at lelegard.fr>; users <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  (thierry at lelegard.fr)
> 
> -----Original Message-----
> From: Pierre-Alain <pierre-alain at toret.fr>
> To: John <dragonflybsd at marino.st>; Thierry <thierry at lelegard.fr>
> Cc: users <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:// 
>> 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 <thierry at lelegard.fr 
>> <mailto:thierry at lelegard.fr>> wrote:
>>
>>      Hi,
>>
>>      I maintain an open source project (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  (thierry at lelegard.fr 
>> <mailto:thierry at lelegard.fr>)
>>
> 