From thierry at lelegard.fr  Fri Feb  6 05:57:51 2026
From: thierry at lelegard.fr (Thierry =?utf-8?Q?Lel=C3=A9gard?=)
Date: Fri, 6 Feb 2026 13:57:51 +0000 (UTC)
Subject: OpenSSL: no "legacy" provider
Message-ID: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>

Hi,

I maintain an open source project (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)

From dragonflybsd at marino.st  Fri Feb  6 06:03:58 2026
From: dragonflybsd at marino.st (John Marino (DragonFly))
Date: Fri, 6 Feb 2026 08:03:58 -0600
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
Message-ID: <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>

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://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> wrote:

> Hi,
>
> I maintain an open source project (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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20260206/340260db/attachment.htm>

From pierre-alain at toret.fr  Fri Feb  6 06:42:44 2026
From: pierre-alain at toret.fr (Pierre-Alain TORET)
Date: Fri, 6 Feb 2026 15:42:44 +0100
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
Message-ID: <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>

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


From thierry at lelegard.fr  Fri Feb  6 07:03:46 2026
From: thierry at lelegard.fr (Thierry =?utf-8?Q?Lel=C3=A9gard?=)
Date: Fri, 6 Feb 2026 15:03:46 +0000 (UTC)
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <CAONZFgO9WO2hw=o5T=8LHharnkr7hchaqxDVPmRZ2F1ax2vvQA@mail.gmail.com>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <CAONZFgO9WO2hw=o5T=8LHharnkr7hchaqxDVPmRZ2F1ax2vvQA@mail.gmail.com>
Message-ID: <427548247.1486960.1770390226503.JavaMail.zimbra@lelegard.fr>

Hi John,

Thanks for your response. First, let me say that I am not a DragonFlyBSD specialist.

Let me also provide some context. My project compiles on Linux, macOS, FreeBSD,
NetBSD with OpenSSL. I have an issue on DragonFly (and another one on OpenBSD
but this is obviously off-topic here). The project also works on Windows but
using the native MS cryptographic library, not OpenSSL.

Most users are on Linux, Windows, macOS, and maybe FreeBSD. I try to expand the
supported base to all BSD systems.

On DragonFly, I use the OpenSSL package which was installed using "pkg install openssl".

Using LibreSSL is not an option. When LibreSSL was forked, OpenSSL was in version 1.x
and LibreSSL was compatible. This is no longer the case. The API's have diverged, not
that much, but sufficiently to break applications using modern v3.x functions.

So, at some point, using the real OpenSSL became a necessity for some applications.
This will be more and more the case when more applications use the v3 API. I must
add that LibreSSL was created, I think, in response to the infamous HeartBleed bug,
also considering that the code was crappy. This situation has changed. Because so
much of the Internet relied on OpenSSL, a general effort was provided and, somehow,
the quality has been improved to some acceptable level. About cryptography (my
concern), all improvements are implemented on OpenSSL, especially the optimizations
for AVX512 (OpenSSL 3.1) and Arm64 SIMD and SVE. Today, LibreSSL is less relevant,
less at the state of the art. 

This is why I need OpenSSL, the one which is in /usr/local, not the default LibreSSL.

In this OpenSSL package, the "legacy" provider is missing. This is the problem
I need to fix.

-Thierry Lel?gard (thierry at lelegard.fr)


-----Original Message-----
From: John <dragonflybsd at marino.st>
To: Thierry <thierry at lelegard.fr>
Date: Friday, 6 February 2026 3:06 PM CET
Subject: Re: OpenSSL: no "legacy" provider


I need to add this -- on dports?you might be limited to new libreSSL.? Ravenports supports simultaneous installations of SSL (openssl 1.1, openSSL 3.0, libreSSL x, etc) whereas dports?can't do that due to conflicting installation.


On Fri, Feb 6, 2026 at 8:03?AM John Marino (DragonFly) <dragonflybsd at marino.st> wrote:

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://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> wrote:

Hi,

I maintain an open source project (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)

From thierry at lelegard.fr  Fri Feb  6 07:30:01 2026
From: thierry at lelegard.fr (Thierry =?utf-8?Q?Lel=C3=A9gard?=)
Date: Fri, 6 Feb 2026 15:30:01 +0000 (UTC)
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
Message-ID: <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>

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 &quot;legacy&quot; 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>)
> 


From thierry at lelegard.fr  Fri Feb  6 07:42:57 2026
From: thierry at lelegard.fr (Thierry =?utf-8?Q?Lel=C3=A9gard?=)
Date: Fri, 6 Feb 2026 15:42:57 +0000 (UTC)
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <CAONZFgPURG7gyQUHM9HYgPM-2pSyaVfXNDS8dHLm2BToa+xhpQ@mail.gmail.com>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <CAONZFgO9WO2hw=o5T=8LHharnkr7hchaqxDVPmRZ2F1ax2vvQA@mail.gmail.com>
 <427548247.1486960.1770390226503.JavaMail.zimbra@lelegard.fr>
 <CAONZFgOko5G1j4sd+sGpQtk8EycNiN4zKNX8jRG1BKty+L1bmw@mail.gmail.com>
 <CAONZFgPURG7gyQUHM9HYgPM-2pSyaVfXNDS8dHLm2BToa+xhpQ@mail.gmail.com>
Message-ID: <1688145167.1559234.1770392577472.JavaMail.zimbra@lelegard.fr>

Hello John,

Indeed, I don't know much about DPorts vs. Ravenports.

On a DragonFly system, after a "default" installation (meaning no explicit
choice?between DPorts vs. Ravenports), which one is used by "pkg install"?

As a general rule of thumb, I always prefer to use the "default" / "native" /
"common" tools on an operating system for package managers, compilers, etc.
It is the best way to meet the requirements of most users.

-Thierry Lel?gard (thierry at lelegard.fr)

-----Original Message-----
From: John <dragonflybsd at marino.st>
To: Thierry <thierry at lelegard.fr>
Date: Friday, 6 February 2026 4:09 PM CET
Subject: Re: OpenSSL: no "legacy" provider


You probably don't know, but Ravenports is supported on FreeBSD, NetBSD, LInux, and OmniOS.? It used to support MacOS but the Mach-O file formats were obnoxious and I dropped it.


On Fri, Feb 6, 2026 at 9:07?AM John Marino (DragonFly) <dragonflybsd at marino.st> wrote:

well, Pierre-Alain told you how to build OpenSSL on Dports.
And I indicated that you could use ravenports (location changes to /raven/lib/openssl30 in that case)


It would be nice if Ravenports was the only package repository for DragonFly.? That would be the goal but we're not quite there yet, probably because of chromium.


On Fri, Feb 6, 2026 at 9:03?AM Thierry Lel?gard <thierry at lelegard.fr> wrote:

Hi John,

Thanks for your response. First, let me say that I am not a DragonFlyBSD specialist.

Let me also provide some context. My project compiles on Linux, macOS, FreeBSD,
NetBSD with OpenSSL. I have an issue on DragonFly (and another one on OpenBSD
but this is obviously off-topic here). The project also works on Windows but
using the native MS cryptographic library, not OpenSSL.

Most users are on Linux, Windows, macOS, and maybe FreeBSD. I try to expand the
supported base to all BSD systems.

On DragonFly, I use the OpenSSL package which was installed using "pkg install openssl".

Using LibreSSL is not an option. When LibreSSL was forked, OpenSSL was in version 1.x
and LibreSSL was compatible. This is no longer the case. The API's have diverged, not
that much, but sufficiently to break applications using modern v3.x functions.

So, at some point, using the real OpenSSL became a necessity for some applications.
This will be more and more the case when more applications use the v3 API. I must
add that LibreSSL was created, I think, in response to the infamous HeartBleed bug,
also considering that the code was crappy. This situation has changed. Because so
much of the Internet relied on OpenSSL, a general effort was provided and, somehow,
the quality has been improved to some acceptable level. About cryptography (my
concern), all improvements are implemented on OpenSSL, especially the optimizations
for AVX512 (OpenSSL 3.1) and Arm64 SIMD and SVE. Today, LibreSSL is less relevant,
less at the state of the art.

This is why I need OpenSSL, the one which is in /usr/local, not the default LibreSSL.

In this OpenSSL package, the "legacy" provider is missing. This is the problem
I need to fix.

-Thierry Lel?gard (thierry at lelegard.fr)


-----Original Message-----
From: John <dragonflybsd at marino.st>
To: Thierry <thierry at lelegard.fr>
Date: Friday, 6 February 2026 3:06 PM CET
Subject: Re: OpenSSL: no "legacy" provider


I need to add this -- on dports?you might be limited to new libreSSL.? Ravenports supports simultaneous installations of SSL (openssl 1.1, openSSL 3.0, libreSSL x, etc) whereas dports?can't do that due to conflicting installation.


On Fri, Feb 6, 2026 at 8:03?AM John Marino (DragonFly) <dragonflybsd at marino.st> wrote:

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://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> wrote:

Hi,

I maintain an open source project (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)

From pierre-alain at toret.fr  Fri Feb  6 09:45:02 2026
From: pierre-alain at toret.fr (Pierre-Alain TORET)
Date: Fri, 6 Feb 2026 18:45:02 +0100
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
 <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
Message-ID: <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>

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 &quot;legacy&quot; 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>)
>>
> 


From thierry at lelegard.fr  Fri Feb  6 15:43:58 2026
From: thierry at lelegard.fr (thierry at lelegard.fr)
Date: Sat, 7 Feb 2026 00:43:58 +0100
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
 <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
 <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>
Message-ID: <000a01dc97c2$76ffd6c0$64ff8440$@lelegard.fr>

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 &quot;legacy&quot; 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>)
>>
> 



From justin at shiningsilence.com  Fri Feb  6 16:15:10 2026
From: justin at shiningsilence.com (Justin Sherrill)
Date: Fri, 6 Feb 2026 19:15:10 -0500
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <000a01dc97c2$76ffd6c0$64ff8440$@lelegard.fr>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
 <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
 <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>
 <000a01dc97c2$76ffd6c0$64ff8440$@lelegard.fr>
Message-ID: <CA+YR8=2quc=go6O4Tyz0raNb9pR61sX7RSt36nCxw4HFJCwqow@mail.gmail.com>

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 <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 (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 &quot;legacy&quot; 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>)
> >>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20260206/2f79c750/attachment-0001.htm>

From thierry at lelegard.fr  Sat Feb  7 08:15:50 2026
From: thierry at lelegard.fr (thierry at lelegard.fr)
Date: Sat, 7 Feb 2026 17:15:50 +0100
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <CA+YR8=2quc=go6O4Tyz0raNb9pR61sX7RSt36nCxw4HFJCwqow@mail.gmail.com>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
 <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
 <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>
 <000a01dc97c2$76ffd6c0$64ff8440$@lelegard.fr>
 <CA+YR8=2quc=go6O4Tyz0raNb9pR61sX7RSt36nCxw4HFJCwqow@mail.gmail.com>
Message-ID: <000f01dc984d$0728f260$157ad720$@lelegard.fr>

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 &quot;legacy&quot; 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>)
>>
> 



From thierry at lelegard.fr  Sat Feb  7 10:22:24 2026
From: thierry at lelegard.fr (thierry at lelegard.fr)
Date: Sat, 7 Feb 2026 19:22:24 +0100
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <CAONZFgOuqUtO21HDkaRYALiphVyYJEvyDDKbQAUbxKD9dmJ7RA@mail.gmail.com>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
 <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
 <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>
 <000a01dc97c2$76ffd6c0$64ff8440$@lelegard.fr>
 <CA+YR8=2quc=go6O4Tyz0raNb9pR61sX7RSt36nCxw4HFJCwqow@mail.gmail.com>
 <000f01dc984d$0728f260$157ad720$@lelegard.fr>
 <CAONZFgOuqUtO21HDkaRYALiphVyYJEvyDDKbQAUbxKD9dmJ7RA@mail.gmail.com>
Message-ID: <38F6367B-74E5-40E4-B904-6E7103BE4640@lelegard.fr>

I am afraid that I have no idea about what ? privatizing base libraries ? means in the context of DragonFly.

My standpoint as a developer is more application-centric, cross-operating systems. People do not use an operating system. They use applications, which then require an operating system to run. So, the main point is interoperability, ease of port, consistency and reliability of configuration across users. The worst situation, for the developer and the users, is an operating system allowing heterogeneous and incompatible configurations. Typically, user A: ? It works for me ? and user B: ? It does not work for me ?. Then, the developer realizes that his configuration, user A?s and user B?s are all different and it is impossible to propose a reliable application configuration which suits all users. Usually, the result is that everybody step out?

In this perspective, having two distinct package managers is a disaster. You develop with one in mind, then it sometimes breaks with the other one. And then a third one emerges, etc. An environment becomes reliable when any user is confident to be able to use any application without configuration nightmare. In this respect, the original problem of this discussion, OpenSSL without ? legacy ? provider, is a good example. Everywhere, OpenSSL comes with a given way of working, a set of known providers. And applications count on that common set of features. Then comes one operating system which breaks the contract, missing some features, and the applications break...

I have no idea which package manager is better, DPorts or RavenPorts, but there is already one too many?.

Be standard, that is what users need. The problem is not if package manager A or B is better. The question is to have one on which we all agree, whether we like it or not. But it reliably works the same way for everyone. At some point, we need to be hash. Once upon a time, on macOS, there was the old MacPort. With some limitations. Then came Homebrew, much larger, much more flexible, much faster inclusion time for packages, much better integration. And everybody used it. It is the de-facto standard. TSDuck, my project, is in Homebrew and everything is automated and fast. I haven?t received any request to port to MacPort but, in case, my response is ready: ? not supported, use Homebrew, like anyone else, I haven?t time to lose supporting many different environments for one operating system ?. That is how package managers live and die?

-Thierry


> Le 7 f?vr. 2026 ? 17:42, John Marino (DragonFly) <dragonflybsd at marino.st> a ?crit :
> 
> It's my opinion that all base libraries should be private, including (or especially) openssl.
> Most of them are (with a very problem of having liblzma exposed from base).
> 
> So using 3rd party library (dports, ravenports) is the correct way to go.
> 
> Which means an older libressl in base shouldn't be a problem unless there's a known vulnerability.
> 
> my vote would be to privatize the remaining exposed base libraries (updating if necessary) for a full release.
> 
> 
> On Sat, Feb 7, 2026 at 10:16?AM <thierry at lelegard.fr <mailto:thierry at lelegard.fr>> wrote:
>> 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 <mailto:thierry at lelegard.fr>)
>> 
>> From: Justin Sherrill <justin at shiningsilence.com <mailto:justin at shiningsilence.com>> 
>> Sent: Saturday, 7 February, 2026 01:15
>> To: thierry at lelegard.fr <mailto:thierry at lelegard.fr>
>> Cc: Pierre-Alain TORET <pierre-alain at toret.fr <mailto:pierre-alain at toret.fr>>; users <users at lists.dragonflybsd.org <mailto: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 <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 <https://bugs.dragonflybsd.org/>. I will create an issue on GitHub.
>> 
>> Thank you for your help.
>> 
>> -Thierry Lel?gard (mailto:thierry at lelegard.fr <mailto:thierry at lelegard.fr>)
>> 
>> -----Original Message-----
>> From: Pierre-Alain TORET <mailto:pierre-alain at toret.fr <mailto:pierre-alain at toret.fr>> 
>> Sent: Friday, 6 February, 2026 18:45
>> To: Thierry Lel?gard <mailto:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>; users <mailto:users at lists.dragonflybsd.org <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 <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 <mailto:thierry at lelegard.fr>)
>> > 
>> > -----Original Message-----
>> > From: Pierre-Alain <mailto:pierre-alain at toret.fr <mailto:pierre-alain at toret.fr>>
>> > To: John <mailto:dragonflybsd at marino.st <mailto:dragonflybsd at marino.st>>; Thierry <mailto:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>
>> > Cc: users <mailto:users at lists.dragonflybsd.org <mailto:users at lists.dragonflybsd.org>>
>> > Date: Friday, 6 February 2026 3:42 PM CET
>> > Subject: Re: OpenSSL: no &quot;legacy&quot; 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:thierry at lelegard.fr> 
>> >> <mailto:mailto <mailto:mailto>:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>> wrote:
>> >>
>> >>      Hi,
>> >>
>> >>      I maintain an open source project (http://tsduck.io <http://tsduck.io/> <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:thierry at lelegard.fr> 
>> >> <mailto:mailto <mailto:mailto>:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>)
>> >>
>> > 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20260207/9b41b29f/attachment-0001.htm>

From mneumann at ntecs.de  Sun Feb  8 04:48:32 2026
From: mneumann at ntecs.de (Michael Neumann)
Date: Sun, 08 Feb 2026 13:48:32 +0100
Subject: OpenSSL: no "legacy" provider
In-Reply-To: <38F6367B-74E5-40E4-B904-6E7103BE4640@lelegard.fr>
References: <710430801.1367279.1770386271369.JavaMail.zimbra@lelegard.fr>
 <CAONZFgN_fXLRRG_+u153HnD7xXnbZ4AETFrQY955DADrRm9ecQ@mail.gmail.com>
 <fcc0e40f-c687-4683-8a0f-49e6c7330926@toret.fr>
 <141230397.1541164.1770391801155.JavaMail.zimbra@lelegard.fr>
 <c7ed4578-3d74-4546-bb19-7679ac84907c@toret.fr>
 <000a01dc97c2$76ffd6c0$64ff8440$@lelegard.fr>
 <CA+YR8=2quc=go6O4Tyz0raNb9pR61sX7RSt36nCxw4HFJCwqow@mail.gmail.com>
 <000f01dc984d$0728f260$157ad720$@lelegard.fr>
 <CAONZFgOuqUtO21HDkaRYALiphVyYJEvyDDKbQAUbxKD9dmJ7RA@mail.gmail.com>
 <38F6367B-74E5-40E4-B904-6E7103BE4640@lelegard.fr>
Message-ID: <EE2D74D5-038F-4E62-9AD9-FD021E514273@ntecs.de>



Am 7. Februar 2026 19:22:24 MEZ schrieb "thierry at lelegard.fr" <thierry at lelegard.fr>:
>I am afraid that I have no idea about what ? privatizing base libraries ? means in the context of DragonFly.

It is a library that should only be used for applications that are part of the Dragonfly base distribution, NOT with the "ports" / package manager supplied applications. By making them private, they don't interfere with versions of the same library supplied by the package manager. 


>
>My standpoint as a developer is more application-centric, cross-operating systems. People do not use an operating system. They use applications, which then require an operating system to run. So, the main point is interoperability, ease of port, consistency and reliability of configuration across users. The worst situation, for the developer and the users, is an operating system allowing heterogeneous and incompatible configurations. Typically, user A: ? It works for me ? and user B: ? It does not work for me ?. Then, the developer realizes that his configuration, user A?s and user B?s are all different and it is impossible to propose a reliable application configuration which suits all users. Usually, the result is that everybody step out?
>
>In this perspective, having two distinct package managers is a disaster. You develop with one in mind, then it sometimes breaks with the other one. And then a third one emerges, etc. An environment becomes reliable when any user is confident to be able to use any application without configuration nightmare. In this respect, the original problem of this discussion, OpenSSL without ? legacy ? provider, is a good example. Everywhere, OpenSSL comes with a given way of working, a set of known providers. And applications count on that common set of features. Then comes one operating system which breaks the contract, missing some features, and the applications break...
>
>I have no idea which package manager is better, DPorts or RavenPorts, but there is already one too many?.

I understand your point. Technically, Ravenports could be seen as superior to DPorts, but I think it's good to have the choice. There are some ports that don't exist in Raveports (chrome) and vice versa. Ravenports is generally more up to date and is cross-platform, while Dports is the standard package manager of Dragonfly.

Best regards,

Michael 

>
>Be standard, that is what users need. The problem is not if package manager A or B is better. The question is to have one on which we all agree, whether we like it or not. But it reliably works the same way for everyone. At some point, we need to be hash. Once upon a time, on macOS, there was the old MacPort. With some limitations. Then came Homebrew, much larger, much more flexible, much faster inclusion time for packages, much better integration. And everybody used it. It is the de-facto standard. TSDuck, my project, is in Homebrew and everything is automated and fast. I haven?t received any request to port to MacPort but, in case, my response is ready: ? not supported, use Homebrew, like anyone else, I haven?t time to lose supporting many different environments for one operating system ?. That is how package managers live and die?
>
>-Thierry
>
>
>> Le 7 f?vr. 2026 ? 17:42, John Marino (DragonFly) <dragonflybsd at marino.st> a ?crit :
>> 
>> It's my opinion that all base libraries should be private, including (or especially) openssl.
>> Most of them are (with a very problem of having liblzma exposed from base).
>> 
>> So using 3rd party library (dports, ravenports) is the correct way to go.
>> 
>> Which means an older libressl in base shouldn't be a problem unless there's a known vulnerability.
>> 
>> my vote would be to privatize the remaining exposed base libraries (updating if necessary) for a full release.
>> 
>> 
>> On Sat, Feb 7, 2026 at 10:16?AM <thierry at lelegard.fr <mailto:thierry at lelegard.fr>> wrote:
>>> 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 <mailto:thierry at lelegard.fr>)
>>> 
>>> From: Justin Sherrill <justin at shiningsilence.com <mailto:justin at shiningsilence.com>> 
>>> Sent: Saturday, 7 February, 2026 01:15
>>> To: thierry at lelegard.fr <mailto:thierry at lelegard.fr>
>>> Cc: Pierre-Alain TORET <pierre-alain at toret.fr <mailto:pierre-alain at toret.fr>>; users <users at lists.dragonflybsd.org <mailto: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 <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 <https://bugs.dragonflybsd.org/>. I will create an issue on GitHub.
>>> 
>>> Thank you for your help.
>>> 
>>> -Thierry Lel?gard (mailto:thierry at lelegard.fr <mailto:thierry at lelegard.fr>)
>>> 
>>> -----Original Message-----
>>> From: Pierre-Alain TORET <mailto:pierre-alain at toret.fr <mailto:pierre-alain at toret.fr>> 
>>> Sent: Friday, 6 February, 2026 18:45
>>> To: Thierry Lel?gard <mailto:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>; users <mailto:users at lists.dragonflybsd.org <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 <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 <mailto:thierry at lelegard.fr>)
>>> > 
>>> > -----Original Message-----
>>> > From: Pierre-Alain <mailto:pierre-alain at toret.fr <mailto:pierre-alain at toret.fr>>
>>> > To: John <mailto:dragonflybsd at marino.st <mailto:dragonflybsd at marino.st>>; Thierry <mailto:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>
>>> > Cc: users <mailto:users at lists.dragonflybsd.org <mailto:users at lists.dragonflybsd.org>>
>>> > Date: Friday, 6 February 2026 3:42 PM CET
>>> > Subject: Re: OpenSSL: no &quot;legacy&quot; 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:thierry at lelegard.fr> 
>>> >> <mailto:mailto <mailto:mailto>:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>> wrote:
>>> >>
>>> >>      Hi,
>>> >>
>>> >>      I maintain an open source project (http://tsduck.io <http://tsduck.io/> <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:thierry at lelegard.fr> 
>>> >> <mailto:mailto <mailto:mailto>:thierry at lelegard.fr <mailto:thierry at lelegard.fr>>)
>>> >>
>>> > 
>>> 
>>> 
>