tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Handling system-wide TLS certification bundles for openssl builtin and www/curl



Hi all,

this got lost back in November: I am running multiple prefixes of
pkgsrc packages on CentOS 7, where the OS-provided openssl certificates
reside bundled in /etc/pki/tls, like this:

$ ls -l /etc/ssl
total 0
lrwxrwxrwx 1 root root 16 Nov 18 14:27 certs -> ../pki/tls/certs

$ find /etc/pki/tls/
/etc/pki/tls/
/etc/pki/tls/cert.pem
/etc/pki/tls/certs
/etc/pki/tls/certs/Makefile
/etc/pki/tls/certs/ca-bundle.crt
/etc/pki/tls/certs/ca-bundle.trust.crt
/etc/pki/tls/certs/make-dummy-cert
/etc/pki/tls/certs/renew-dummy-cert
/etc/pki/tls/misc
/etc/pki/tls/misc/CA
/etc/pki/tls/misc/c_hash
/etc/pki/tls/misc/c_info
/etc/pki/tls/misc/c_issuer
/etc/pki/tls/misc/c_name
/etc/pki/tls/openssl.cnf
/etc/pki/tls/private


While I install a version of pkgsrc as a snapshot to a certain prefix
and keep it that way for reproducible (scientific) work based on it, I
do not want it to rely on a fixed version of SSL certificates it
installed via some outdated package. Instead, the system SSL
certificates should be used along with the system openssl which also
gets distro security updates while keeping the functionality stable.

The attached patches

a) extend security/openssl/builtin.mk to detect certificate bundles in
   /etc and
b) make www/curl use that.

Curl needs to be told explicitly to use the certificate bundle.

I hope it is uncontroversial that having multiple independent sets of
TLS certificates is generally not desirable. This would manifest in a
user not being able to get CRAN packages with one install of R while it
would work with another one because curl misses some current cert.

(Future: This is contrasted by the current state of aging CentOS 7
where the provided openssl base version is so old that pkgsrc won't use
it anymore. Currently, I have a script that manually syncs certs from
/etc to the pkgsrc prefix after building packages, possibly repeatedly.
A next step would be to make the pkgsrc-built openssl also use the
system certs directly.)

Thoughts? Could someone apply this to CVS (or build on the basic idea)?


Regards,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg
--- pkgsrc-2015Q4/security/openssl/builtin.mk	2015-03-26 09:05:02.000000000 +0100
+++ pkgsrc/security/openssl/builtin.mk	2016-01-26 15:31:04.972886777 +0100
@@ -214,6 +214,9 @@
 .      else
 SSLDIR=	/boot/common/data/ssl
 .      endif
+# The fresh thing on CentOS 7.
+.    elif exists(/etc/pki/tls)
+SSLDIR=/etc/pki/tls
 .    else
 SSLDIR=	/etc/ssl 		# most likely place
 .    endif
@@ -221,10 +224,14 @@
 SSLDIR=	${PKG_SYSCONFBASEDIR}/openssl
 .  endif
 
+# Again, CentOS 7. Maybe should be set by user in mk.conf?
+.  if exists(${SSLDIR}/certs/ca-bundle.crt)
+SSLCERTBUNDLE=  ${SSLDIR}/certs/ca-bundle.crt
+.  endif
 SSLCERTS=	${SSLDIR}/certs
 SSLKEYS=	${SSLDIR}/private
 
-BUILD_DEFS+=	SSLDIR SSLCERTS SSLKEYS
+BUILD_DEFS+=	SSLDIR SSLCERTBUNDLE SSLCERTS SSLKEYS
 
 # create pc files for builtin version; other versions assumed to contain them
 # If we are using the builtin version, check whether it has a *.pc
--- pkgsrc-2020Q3/www/curl/Makefile	2020-08-31 20:12:32.000000000 +0200
+++ pkgsrc/www/curl/Makefile	2020-11-15 20:44:13.880917249 +0100
@@ -51,3 +51,11 @@
 .include "../../security/openssl/buildlink3.mk"
 .include "../../mk/pthread.buildlink3.mk"
 .include "../../mk/bsd.pkg.mk"
+
+# Openssl builtin detection sets SSLCERTBUNDLE if a bundle is found
+# in /etc/. This is essential to have working curl!
+.if !empty(SSLCERTBUNDLE)
+CONFIGURE_ARGS+=        --with-ca-bundle=${SSLCERTBUNDLE}
+.else
+CONFIGURE_ARGS+=	--with-ca-path=${SSLCERTS}
+.endif


Home | Main Index | Thread Index | Old Index