OpenSSL: no "legacy" provider

Fri Feb 6 09:45:02 PST 2026

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/openssl/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>)
>>
> 