pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/58143: security/gnutls uses wrong trust anchors
The following reply was made to PR pkg/58143; it has been noted by GNATS.
From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, pkgsrc-bugs%NetBSD.org@localhost
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@localhost>
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@localhost>
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--
Home |
Main Index |
Thread Index |
Old Index