NetBSD Problem Report #58143
From www@netbsd.org Fri Apr 12 14:26:22 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id E62491A9239
for <gnats-bugs@gnats.NetBSD.org>; Fri, 12 Apr 2024 14:26:21 +0000 (UTC)
Message-Id: <20240412142620.5EDDF1A923A@mollari.NetBSD.org>
Date: Fri, 12 Apr 2024 14:26:20 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: security/gnutls uses wrong trust anchors
X-Send-Pr-Version: www-1.0
>Number: 58143
>Notify-List: dpirate@metalpunks.info
>Category: pkg
>Synopsis: security/gnutls uses wrong trust anchors
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: riastradh
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Apr 12 14:30:00 +0000 2024
>Last-Modified: Tue Jan 07 19:20:03 +0000 2025
>Originator: Taylor R Campbell
>Release: current
>Organization:
The GNU/kNetTLS Trustation
>Environment:
>Description:
security/gnutls depends on security/mozilla-rootcerts and configures with:
CONFIGURE_ARGS+= --with-default-trust-store-file=${PREFIX}/share/mozilla-rootcerts/cacert.pem
This doesn't respect system configuration about TLS trust anchors, like security/openssl/builtin.mk does.
>How-To-Repeat:
code inspection
>Fix:
Yes, please!
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: pkg-manager->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Mon, 30 Dec 2024 14:51:28 +0000
Responsible-Changed-Why:
I am taking a look at this mess
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, pkgsrc-bugs@NetBSD.org
Cc:
Subject: Re: pkg/58143: security/gnutls uses wrong trust anchors
Date: Mon, 30 Dec 2024 14:50:31 +0000
This is a multi-part message in MIME format.
--=_zuuYtksK0C8RJaF9J8AwVVP/KZSlw/L+
[followup previously sent to a duplicate of this PR]
--=_zuuYtksK0C8RJaF9J8AwVVP/KZSlw/L+
Content-Type: message/rfc822
Content-Disposition: inline
Date: Sat, 28 Dec 2024 16:56:16 +0000
From: Taylor R Campbell <riastradh@NetBSD.org>
To: dpirate@metalpunks.info
CC: gnats-bugs@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/58942: The GNUTLS package doesn't use system-wide CA certs
Message-Id: <20241228165617.BDF0984EEF@mail.netbsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
This happens because:
DEPENDS+=3D mozilla-rootcerts-[0-9]*:../../security/mozilla-rootcerts
...
CONFIGURE_ARGS+=3D --with-default-trust-store-file=3D${PREFIX}/share/mozill=
a-rootcerts/cacert.pem
This is wrong for two reasons:
1. it doesn't provide any way to override the decision, because
${PREFIX}/share/mozilla-rootcerts/cacert.pem is part of a package
rather than editable configuration; and
2. it doesn't respect OS-specific certificate stores, like
/etc/openssl/certs on NetBSD or /etc/pki/tls on various Linux
systems.
What this really should do is follow logic somewhat like what's in
security/openssl/builtin.mk for the OS's certificate store, in order
to determine that the correct path on NetBSD is
/etc/openssl/certs/ca-certificates.crt (as used by certctl(8) in
NetBSD>=3D10 and by the security/ca-certificates or
security/mozilla-rootcerts packages in older versions).
Unfortunately, security/openssl/builtin.mk is obviously specific to
OpenSSL -- and doesn't get the right path to the single-file bundle
used by GnuTLS (but it gets the right path to the hashed certificate
directory used by OpenSSL).
So I think we should create a new mk/ssl.mk or mk/ssltrustanchors.mk
or mk/sslcacerts.mk or something to place this logic properly, and use
it consistently both for GnuTLS and for OpenSSL -- and consider
pulling up either that or a more narrowly scoped stop-gap measure to
2024Q4, since this is a security risk when certctl(8) is supposed to
be able to promptly _distrust_ a CA in cases like the Digi-Notar
incident.
I found a handful of other packages that likely have the same issue,
with hard-coded references to share/mozilla-rootcerts:
lang/python27
security/botan3
security/p11-kit
security/qca2-qt5
security/qca2
sysutils/bsdec2-image-upload
--=_zuuYtksK0C8RJaF9J8AwVVP/KZSlw/L+--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/58143: security/gnutls uses wrong trust anchors
Date: Mon, 30 Dec 2024 17:42:34 +0000
This is a multi-part message in MIME format.
--=_fvz4bw6Sgb7EvIjKFB6Nr1oMeWUc8Daj
The attached patch series creates a new mk/ssl.mk and teaches
security/gnutls to use it.
I have not yet systematically changed everything that references
share/mozilla-rootcerts/cacert.pem or SSLCERTBUNDLE or whatever to use
the new mk/ssl.mk because there are some fiddly details for some
packages like www/curl and so this needs some care.
But I have tested gnutls with the attached patch series (which doesn't
affect any other packages) and I think this incremental approach is
low-risk for pullup to 2024Q4. Specifically, I ran `bmake test' (all
tests passed), and verified that it examines the intended path on
NetBSD -- both with ktrace and by moving the file out of the way and
confirming gnutls fails certificate validation.
This should get some other eyeballs and I probably won't have time to
deal with it for another week so if someone else wants to commit, feel
free -- detailed commit messages and comments explaining what's going
on are already written.
--=_fvz4bw6Sgb7EvIjKFB6Nr1oMeWUc8Daj
Content-Type: text/plain; charset="ISO-8859-1"; name="pr58143-gnutlsanchors"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr58143-gnutlsanchors.patch"
>From 1f4f900cb6075174e8f380f61b0b01b9f3682939 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell <riastradh@NetBSD.org>
Date: Mon, 30 Dec 2024 15:14:37 +0000
Subject: [PATCH 1/2] mk/ssl.mk, mk/ssldir.mk: New files to define some
TLS-related paths.
Nothing uses these new files yet, so this cannot break anything.
Packages should opt into using this as they are tested with it -- in
particular, www/curl may need some care because on NetBSD this
changes SSLCERTBUNDLE from undefined (and functionally empty) to a
path, which affects how www/curl builds (but only www/curl as far as
I can tell).
Packages can include "../../mk/ssl.mk" to get at the following
variables for TLS-related paths, with the following current values:
SSLDIR directory where TLS-related files live
NetBSD: /etc/openssl (even for, say, gnutls)
Fedora: /etc/pki/tls
Haiku: /boot/system/data/ssl or /boot/common/data/ssl
Others: /etc/ssl
SSLCERTS TLS trust anchors in OpenSSL hashed cert directory
Everywhere: ${SSLDIR}/certs
SSLCERTBUNDLE TLS trust anchors in single-file concatenated PEM
NetBSD: ${SSLDIR}/certs/ca-certificates.crt (*)
Others: ${SSLDIR}/certs/ca-bundle.crt if exists
SSLKEYS directory of per-service TLS private keys
Everywhere: ${SSLDIR}/private
This logic is extracted almost verbatim (modulo indentation) from
security/openssl/builtin.mk, split into two files because of how SSLDIR
is conditional on builtin vs non-builtin OpenSSL.
(*) The one difference is: On NetBSD, SSLCERTBUNDLE is
/etc/openssl/certs/ca-certificates.crt, not undefined.
Why /etc/openssl on NetBSD, even though it is used by
non-OpenSSL applications?
=3D> Upstream OpenSSL uses /etc/ssl by default, but NetBSD's OpenSSL
has been built to use /etc/openssl for decades. Other systems
have expanded the domain of the path /etc/ssl to non-OpenSSL
software, or changed it to /etc/pki/tls, but the name stuck as
/etc/openssl on NetBSD, and it has carried over to any systems
using security/mozilla-rootcerts or security/ca-certificates.
To keep this change narrowly scoped to what I can test, I'm
limiting it to NetBSD for now -- but this is worth revisiting for
other operating systems if pkgsrc has traditionally been used on
those systems with security/mozilla-rootcerts instead of
OS-provided trust anchors.
=3D> In NetBSD>=3D10, certctl(8) manages trust anchors under
/etc/openssl/certs out of the box -- this was chosen to match
existing practice on NetBSD so most existing applications would
continue to work unmodified.
Why ${SSLDIR}/certs/ca-certificates.crt instead of
${SSLDIR}/certs/ca-bundle.crt on NetBSD?
=3D> The security/mozilla-rootcerts `mozilla-rootcerts install' command
has used the file name `ca-certificate.crt' for over a decade,
since mozilla-rootcerts-1.0.20121229nb1 back in 2013; likewise the
security/mozilla-rootcerts-openssl package since it was introduced
in 2015.
(Originally it put this in /etc/ssl/certs/ca-certificates.crt
instead of /etc/openssl/certs/ca-certificates.crt, but that was
changed in mozilla-rootcerts-1.0.20170121nb3 back in 2017,
presumably so it would match how NetBSD ships OpenSSL (except when
using pkgsrc OpenSSL, in which case it uses
${PKG_SYSCONFDIR}/openssl/certs/ca-certificates.crt). That
compatibility break happened long enough ago that I don't think
it's worth trying to restore anything about it -- and we can
probably safely ditch any patches that point, e.g., Go at
/etc/ssl/certs/ca-certificates.crt at this point.)
=3D> In NetBSD>=3D10, certctl(8) puts this file at
/etc/openssl/certs/ca-certificates.crt out of the box -- this was
chosen to match existing practice on NetBSD so most existing
applications would continue to work unmodified.
---
mk/ssl.mk | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
mk/ssldir.mk | 29 +++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
create mode 100644 mk/ssl.mk
create mode 100644 mk/ssldir.mk
diff --git a/mk/ssl.mk b/mk/ssl.mk
new file mode 100644
index 000000000000..3f4f987d2174
--- /dev/null
+++ b/mk/ssl.mk
@@ -0,0 +1,49 @@
+# $NetBSD$
+
+# SSL/TLS-related paths for trust anchors, certificates, private keys.
+#
+# Packages should normally include security/openssl/buildlink3.mk or
+# similar, not mk/ssl.mk, for these variables.
+#
+# System-defined variables:
+#
+# SSLDIR
+# Path to directory where TLS-related files, including trust
+# anchors (CA certificates) and sometimes private keys, are
+# stored.
+#
+# Normally SSLDIR is defined by mk/ssldir.mk, but it may be
+# defined differently by security/openssl/builtin.mk when using
+# OpenSSL from pkgsrc instead of builtin.
+#
+# SSLCERTS
+# Path to directory of TLS trust anchors in OpenSSL hashed
+# certificate format (see openssl_rehash(1)).
+#
+# SSLCERTBUNDLE
+# Path to file of TLS trust anchors in concatenated PEM bundle
+# format. Undefined or empty if the host OS does not ship one.
+#
+# SSLKEYS
+# Path to directory of per-service TLS private keys.
+#
+
+.ifndef SSLDIR
+. include "ssldir.mk"
+.endif
+
+.include "bsd.fast.prefs.mk"
+
+SSLCERTS=3D ${SSLDIR}/certs
+# Some systems use CA bundles instead of files and hashed symlinks.
+# Continue to define SSLCERTS because it's unclear if that's the
+# directory that has one file per cert, or the directory that contains
+# trust anchor config in some fortm.
+.if ${OPSYS} =3D=3D "NetBSD"
+SSLCERTBUNDLE=3D ${SSLDIR}/certs/ca-certificates.crt
+.elif exists(${_CROSS_DESTDIR:U}${SSLDIR}/certs/ca-bundle.crt)
+SSLCERTBUNDLE=3D ${SSLDIR}/certs/ca-bundle.crt
+.endif
+SSLKEYS=3D ${SSLDIR}/private
+
+BUILD_DEFS+=3D SSLDIR SSLCERTS SSLCERTBUNDLE SSLKEYS
diff --git a/mk/ssldir.mk b/mk/ssldir.mk
new file mode 100644
index 000000000000..a17dfa139291
--- /dev/null
+++ b/mk/ssldir.mk
@@ -0,0 +1,29 @@
+# $NetBSD$
+
+# used by ssl.mk
+# used by ../security/openssl/builtin.mk
+#
+# Packages should not include this file directly. Instead, they should
+# include either security/openssl/buildlink3.mk or mk/ssl.mk.
+
+.include "bsd.fast.prefs.mk"
+
+.if ${OPSYS} =3D=3D "NetBSD"
+SSLDIR=3D /etc/openssl
+.elif ${OPSYS} =3D=3D "Linux"
+. if exists(${_CROSS_DESTDIR:U}/etc/pki/tls)
+# Some distributions have moved to /etc/pki/tls, with incomplete
+# symlinks from /etc/ssl. Prefer the new location if it exists
+SSLDIR=3D /etc/pki/tls
+. else
+SSLDIR=3D /etc/ssl # standard location
+. endif
+.elif ${OPSYS} =3D=3D "Haiku"
+. if exists(${_CROSS_DESTDIR:U}/boot/system/data/ssl)
+SSLDIR=3D /boot/system/data/ssl
+. else
+SSLDIR=3D /boot/common/data/ssl
+. endif
+.else
+SSLDIR=3D /etc/ssl # most likely place
+.endif
>From 5483b2e6a99481d7d66707658feaa3ccd89cf26c Mon Sep 17 00:00:00 2001
From: Taylor R Campbell <riastradh@NetBSD.org>
Date: Mon, 30 Dec 2024 16:36:12 +0000
Subject: [PATCH 2/2] security/gnutls: Use system TLS trust anchors.
Until 2018, gnutls would search at _build-time_ for one of various
files /etc/ssl/ca-bundle.pem, /etc/ssl/certs/ca-certificates.crt,
/etc/pki/tls/cert.pem, &c., for trust anchors, and bake that path
into the build product -- or, if none of those existed at build-time,
it would bake _nothing_ into the build product and require programs
doing TLS to specify trust anchors explicitly; the gnutls function
gnutls_x509_trust_list_add_system_trust would fail with
GNUTLS_E_UNIMPLEMENTED_FEATURE.
In 2018, gnutls was changed to depend on mozilla-rootcerts and use
${PREFIX}/share/mozilla-rootcerts/cacert.pem. This was expedient for
NetBSD which (a) had no trust anchors shipped out of the box until
10.0 but (b) would usually be configured with mozilla-rootcerts
anyway, but wrong, because:
1. The system may manage TLS trust anchors differently, e.g. on
Fedora they're somewhere in /etc/pki/tls, or even if you install
trust anchors from pkgsrc you might use security/ca-certificates
instead of security/mozilla-rootcerts.
2. Even if the system uses Mozilla's trust anchors, there is no way
for an operator to safely selectively override individual CA
certificates, like nixing Digi-Notar after their compromise --
${PREFIX}/share/mozilla-rootcerts/cacert.pem is a static file that
is not allowed to change, not an editable configuration file.
With this change, on platforms where mk/ssl.mk defines SSLCERTBUNDLE,
gnutls will look there; on platforms without it, gnutls will revert
to its original default of checking various paths at build-time. For
systems where the binary packages are built without trust anchors at
build-time, but where there is a fixed path known at build-time where
the trust anchors will be at run-time, mk/ssl.mk should be adapted to
set SSLCERTBUNDLE.
PR pkg/58143: security/gnutls uses wrong trust anchors
---
security/gnutls/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/security/gnutls/Makefile b/security/gnutls/Makefile
index db7ab93514e5..4501f8570fab 100644
--- a/security/gnutls/Makefile
+++ b/security/gnutls/Makefile
@@ -1,7 +1,7 @@
# $NetBSD: Makefile,v 1.262 2024/11/14 22:21:29 wiz Exp $
=20
DISTNAME=3D gnutls-3.8.8
-PKGREVISION=3D 2
+PKGREVISION=3D 3
CATEGORIES=3D security devel
MASTER_SITES=3D https://www.gnupg.org/ftp/gcrypt/gnutls/v${PKGVERSION_NORE=
V:R}/
EXTRACT_SUFX=3D .tar.xz
@@ -11,7 +11,7 @@ HOMEPAGE=3D https://www.gnutls.org/
COMMENT=3D Transport Layer Security library
LICENSE=3D gnu-gpl-v3 AND gnu-lgpl-v2.1
=20
-DEPENDS+=3D mozilla-rootcerts-[0-9]*:../../security/mozilla-rootcerts
+.include "../../mk/ssl.mk"
=20
PLIST_SRC=3D PLIST
=20
@@ -28,7 +28,7 @@ CONFIGURE_ARGS+=3D --disable-openssl-compatibility
CONFIGURE_ARGS+=3D --without-idn
CONFIGURE_ARGS+=3D --without-tpm
CONFIGURE_ARGS+=3D --disable-valgrind-tests
-CONFIGURE_ARGS+=3D --with-default-trust-store-file=3D${PREFIX}/share/mozil=
la-rootcerts/cacert.pem
+CONFIGURE_ARGS+=3D ${empty(SSLCERTBUNDLE):?:--with-default-trust-store-fil=
e=3D${SSLCERTBUNDLE}}
CONFIGURE_ARGS+=3D --with-libintl-prefix=3D${BUILDLINK_PREFIX.gettext}
=20
# Assembler support is broken for SunOS in 3.2.9.
--=_fvz4bw6Sgb7EvIjKFB6Nr1oMeWUc8Daj--
From: Leonardo Taccari <leot@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/58143: security/gnutls uses wrong trust anchors
Date: Tue, 31 Dec 2024 11:44:53 +0100
Hello Taylor,
Taylor R Campbell writes:
> The attached patch series creates a new mk/ssl.mk and teaches
> security/gnutls to use it.
>
> I have not yet systematically changed everything that references
> share/mozilla-rootcerts/cacert.pem or SSLCERTBUNDLE or whatever to use
> the new mk/ssl.mk because there are some fiddly details for some
> packages like www/curl and so this needs some care.
>
> But I have tested gnutls with the attached patch series (which doesn't
> affect any other packages) and I think this incremental approach is
> low-risk for pullup to 2024Q4. Specifically, I ran `bmake test' (all
> tests passed), and verified that it examines the intended path on
> NetBSD -- both with ktrace and by moving the file out of the way and
> confirming gnutls fails certificate validation.
>
> This should get some other eyeballs and I probably won't have time to
> deal with it for another week so if someone else wants to commit, feel
> free -- detailed commit messages and comments explaining what's going
> on are already written.
> [...]
Looks good to me!
Thank you very much for fixing and improving that!
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58143 CVS commit: pkgsrc/mk
Date: Tue, 7 Jan 2025 19:18:08 +0000
Module Name: pkgsrc
Committed By: riastradh
Date: Tue Jan 7 19:18:08 UTC 2025
Added Files:
pkgsrc/mk: ssl.mk ssldir.mk
Log Message:
mk/ssl.mk, mk/ssldir.mk: New files to define some TLS-related paths.
Nothing uses these new files yet, so this cannot break anything.
Packages should opt into using this as they are tested with it -- in
particular, www/curl may need some care because on NetBSD this
changes SSLCERTBUNDLE from undefined (and functionally empty) to a
path, which affects how www/curl builds (but only www/curl as far as
I can tell).
Packages can include "../../mk/ssl.mk" to get at the following
variables for TLS-related paths, with the following current values:
SSLDIR directory where TLS-related files live
NetBSD: /etc/openssl (even for, say, gnutls)
Fedora: /etc/pki/tls
Haiku: /boot/system/data/ssl or /boot/common/data/ssl
Others: /etc/ssl
SSLCERTS TLS trust anchors in OpenSSL hashed cert directory
Everywhere: ${SSLDIR}/certs
SSLCERTBUNDLE TLS trust anchors in single-file concatenated PEM
NetBSD: ${SSLDIR}/certs/ca-certificates.crt (*)
Others: ${SSLDIR}/certs/ca-bundle.crt if exists
SSLKEYS directory of per-service TLS private keys
Everywhere: ${SSLDIR}/private
This logic is extracted almost verbatim (modulo indentation) from
security/openssl/builtin.mk, split into two files because of how SSLDIR
is conditional on builtin vs non-builtin OpenSSL.
(*) The one difference is: On NetBSD, SSLCERTBUNDLE is
/etc/openssl/certs/ca-certificates.crt, not undefined.
Why /etc/openssl on NetBSD, even though it is used by
non-OpenSSL applications?
=> Upstream OpenSSL uses /etc/ssl by default, but NetBSD's OpenSSL
has been built to use /etc/openssl for decades. Other systems
have expanded the domain of the path /etc/ssl to non-OpenSSL
software, or changed it to /etc/pki/tls, but the name stuck as
/etc/openssl on NetBSD, and it has carried over to any systems
using security/mozilla-rootcerts or security/ca-certificates.
To keep this change narrowly scoped to what I can test, I'm
limiting it to NetBSD for now -- but this is worth revisiting for
other operating systems if pkgsrc has traditionally been used on
those systems with security/mozilla-rootcerts instead of
OS-provided trust anchors.
=> In NetBSD>=10, certctl(8) manages trust anchors under
/etc/openssl/certs out of the box -- this was chosen to match
existing practice on NetBSD so most existing applications would
continue to work unmodified.
Why ${SSLDIR}/certs/ca-certificates.crt instead of
${SSLDIR}/certs/ca-bundle.crt on NetBSD?
=> The security/mozilla-rootcerts `mozilla-rootcerts install' command
has used the file name `ca-certificate.crt' for over a decade,
since mozilla-rootcerts-1.0.20121229nb1 back in 2013; likewise the
security/mozilla-rootcerts-openssl package since it was introduced
in 2015.
(Originally it put this in /etc/ssl/certs/ca-certificates.crt
instead of /etc/openssl/certs/ca-certificates.crt, but that was
changed in mozilla-rootcerts-1.0.20170121nb3 back in 2017,
presumably so it would match how NetBSD ships OpenSSL (except when
using pkgsrc OpenSSL, in which case it uses
${PKG_SYSCONFDIR}/openssl/certs/ca-certificates.crt). That
compatibility break happened long enough ago that I don't think
it's worth trying to restore anything about it -- and we can
probably safely ditch any patches that point, e.g., Go at
/etc/ssl/certs/ca-certificates.crt at this point.)
=> In NetBSD>=10, certctl(8) puts this file at
/etc/openssl/certs/ca-certificates.crt out of the box -- this was
chosen to match existing practice on NetBSD so most existing
applications would continue to work unmodified.
Preparation for (among other fixes):
PR pkg/58143: security/gnutls uses wrong trust anchors
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 pkgsrc/mk/ssl.mk pkgsrc/mk/ssldir.mk
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58143 CVS commit: pkgsrc/security/gnutls
Date: Tue, 7 Jan 2025 19:19:34 +0000
Module Name: pkgsrc
Committed By: riastradh
Date: Tue Jan 7 19:19:34 UTC 2025
Modified Files:
pkgsrc/security/gnutls: Makefile
Log Message:
security/gnutls: Use system TLS trust anchors.
Until 2018, gnutls would search at _build-time_ for one of various
files /etc/ssl/ca-bundle.pem, /etc/ssl/certs/ca-certificates.crt,
/etc/pki/tls/cert.pem, &c., for trust anchors, and bake that path
into the build product -- or, if none of those existed at build-time,
it would bake _nothing_ into the build product and require programs
doing TLS to specify trust anchors explicitly; the gnutls function
gnutls_x509_trust_list_add_system_trust would fail with
GNUTLS_E_UNIMPLEMENTED_FEATURE.
In 2018, gnutls was changed to depend on mozilla-rootcerts and use
${PREFIX}/share/mozilla-rootcerts/cacert.pem. This was expedient for
NetBSD which (a) had no trust anchors shipped out of the box until
10.0 but (b) would usually be configured with mozilla-rootcerts
anyway, but wrong, because:
1. The system may manage TLS trust anchors differently, e.g. on
Fedora they're somewhere in /etc/pki/tls, or even if you install
trust anchors from pkgsrc you might use security/ca-certificates
instead of security/mozilla-rootcerts.
2. Even if the system uses Mozilla's trust anchors, there is no way
for an operator to safely selectively override individual CA
certificates, like nixing Digi-Notar after their compromise --
${PREFIX}/share/mozilla-rootcerts/cacert.pem is a static file that
is not allowed to change, not an editable configuration file.
With this change, on platforms where mk/ssl.mk defines SSLCERTBUNDLE,
gnutls will look there; on platforms without it, gnutls will revert
to its original default of checking various paths at build-time. For
systems where the binary packages are built without trust anchors at
build-time, but where there is a fixed path known at build-time where
the trust anchors will be at run-time, mk/ssl.mk should be adapted to
set SSLCERTBUNDLE.
PR pkg/58143: security/gnutls uses wrong trust anchors
To generate a diff of this commit:
cvs rdiff -u -r1.262 -r1.263 pkgsrc/security/gnutls/Makefile
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2025
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home