OpenSSL: no "legacy" provider

Fri Feb 6 16:15:10 PST 2026

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 "legacy" provider
> >
> >
> > Hi Thierry,
> >
> > concerning DPorts, there is the LEGACY option available :
> >
> > https://gitweb.dragonflybsd.org/?p=dports.git;a=blob;f=security/openss
> > l/Makefile;h=13d4729473fec2601acac1aaa9bd81526b70946b;hb=HEAD#l71
> >
> > But if you look at the line defining OPTIONS_DEFAULT, it's disabled.
> > So you would need to rebuild the package with that LEGACY option
> > enabled to get the legacy provider module built-in.
> >
> > It's building fine on current master.
> >
> > Le 06/02/2026 à 15:03, John Marino (DragonFly) a écrit :
> >> So between FreeBSD and NetBSD you are mixing up your SSL sources.
> >> You quoted the base SSL on FreeBSD and you quoted the pkgsrc version of
> openssl.
> >>
> >> So I assume you are looking at the base SSL of DragonFly which is
> >> actually an older libreSSL.
> >>
> >> What you should be looking at is the dports or Ravenports version of
> >> openssl 3.0, because you would be linking with those, not the base
> >> SSL library.
> >>
> >> For ravenports, openssl3 does indeed install a legacy.so.
> >> https://www.ravenports.com/catalog/bucket_B9/openssl30/std/ <https://
> >> www.ravenports.com/catalog/bucket_B9/openssl30/std/>
> >> https://raw.githubusercontent.com/Ravenports/Ravenports/master/
> >> bucket_B9/openssl30 <https://raw.githubusercontent.com/Ravenports/
> >> Ravenports/master/bucket_B9/openssl30>
> >>
> >> John
> >>
> >>
> >> On Fri, Feb 6, 2026 at 7:58 AM Thierry Lelégard <thierry at lelegard.fr
> >> <mailto:thierry at lelegard.fr>> wrote:
> >>
> >>      Hi,
> >>
> >>      I maintain an open source project (tsduck.io <http://tsduck.io>)
> >>      which uses OpenSSL as cryptographic
> >>      library. For some old format, DES is used. No need to comment why
> >>      DES shall no
> >>      longer be used, it's for management of old data only.
> >>
> >>      With OpenSSL, DES is now part of the "legacy" provider module. The
> >>      provider must
> >>      be explicitly activated in the application.
> >>
> >>      On FreeBSD 15.0 with OpenSSL 3.5.4, the legacy provider module is
> in
> >>      /usr/lib/ossl-modules/legacy.so.
> >>
> >>      On NetBSD 9.3 with OpenSSL 3.6.0, it is in /usr/pkg/lib/ossl-
> >>      modules/legacy.so.
> >>
> >>      However, on DragonFly BSD 6.4.2 with OpenSSL 3.0.15, there is no
> >>      "legacy" module.
> >>      The only SSL module is the "fips" one in /usr/local/lib/ossl-
> >>      modules/fips.so.
> >>      And of course, all DES operations fail.
> >>
> >>      It is not a matter of OpenSSL version, the principle of "providers"
> >>      was introduced
> >>      in 3.0 and the legacy provider was created to host old algorithms.
> >>
> >>      Is there a "legacy" OpenSSL module with DragonFly BSD or was it
> >>      completely removed
> >>      from the OpenSSL package? I found no additional package which could
> >>      install it.
> >>
> >>      Thanks for your help.
> >>
> >>      -Thierry Lelégard  (thierry at lelegard.fr
> >> <mailto:thierry at lelegard.fr>)
> >>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20260206/2f79c750/attachment-0001.htm>