OpenSSL: no "legacy" provider
thierry at lelegard.fr
thierry at lelegard.fr
Sat Feb 7 10:22:24 PST 2026
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 "legacy" provider
>> >
>> >
>> > Hi Thierry,
>> >
>> > concerning DPorts, there is the LEGACY option available :
>> >
>> > https://gitweb.dragonflybsd.org/?p=dports.git;a=blob;f=security/openss
>> > l/Makefile;h=13d4729473fec2601acac1aaa9bd81526b70946b;hb=HEAD#l71
>> >
>> > But if you look at the line defining OPTIONS_DEFAULT, it's disabled.
>> > So you would need to rebuild the package with that LEGACY option
>> > enabled to get the legacy provider module built-in.
>> >
>> > It's building fine on current master.
>> >
>> > Le 06/02/2026 à 15:03, John Marino (DragonFly) a écrit :
>> >> So between FreeBSD and NetBSD you are mixing up your SSL sources.
>> >> You quoted the base SSL on FreeBSD and you quoted the pkgsrc version of openssl.
>> >>
>> >> So I assume you are looking at the base SSL of DragonFly which is
>> >> actually an older libreSSL.
>> >>
>> >> What you should be looking at is the dports or Ravenports version of
>> >> openssl 3.0, because you would be linking with those, not the base
>> >> SSL library.
>> >>
>> >> For ravenports, openssl3 does indeed install a legacy.so.
>> >> https://www.ravenports.com/catalog/bucket_B9/openssl30/std/ <https://
>> >> http://www.ravenports.com/catalog/bucket_B9/openssl30/std/>
>> >> https://raw.githubusercontent.com/Ravenports/Ravenports/master/
>> >> bucket_B9/openssl30 <https://raw.githubusercontent.com/Ravenports/
>> >> Ravenports/master/bucket_B9/openssl30>
>> >>
>> >> John
>> >>
>> >>
>> >> On Fri, Feb 6, 2026 at 7:58 AM Thierry Lelégard <mailto:thierry at lelegard.fr <mailto: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>
More information about the Users
mailing list