Package: golang-golang-x-crypto-dev X-Debbugs-CC: debian-go@lists.debian.org When packaging 0.41 for experimental, I noticed an upstream change between 0.39 and 0.41 to add a DER blob with a bunch of X.509 CAs: https://go.googlesource.com/crypto/+/refs/tags/v0.41.0/x509roots/fallback/ https://go.googlesource.com/crypto/+/refs/tags/v0.41.0/x509roots/fallback/bundle.der The DER blob wasn't present in 0.39: https://go.googlesource.com/crypto/+/refs/tags/v0.39.0/x509roots/fallback/ However 0.39 contained a set of CAs in PEM format: https://go.googlesource.com/crypto/+/refs/tags/v0.39.0/x509roots/fallback/bundle.go Arguable this isn't a new concern. Something similar is part of 0.25.0 which we ship with trixie too: https://go.googlesource.com/crypto/+/refs/tags/v0.25.0/x509roots/fallback/bundle.go # CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB # CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS,OU=Ceres,O=FNMT-RCM,C=ES,2.5.4.97=#130f56415445532d51323832363030344a # CN=ACCVRAIZ1,OU=PKIACCV,O=ACCV,C=ES # CN=Actalis Authentication Root CA,O=Actalis S.p.A./03358520967,L=Milan,C=IT # CN=AffirmTrust Commercial,O=AffirmTrust,C=US # CN=AffirmTrust Networking,O=AffirmTrust,C=US # CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US # CN=AffirmTrust Premium,O=AffirmTrust,C=US # CN=Amazon Root CA 1,O=Amazon,C=US # CN=Amazon Root CA 2,O=Amazon,C=US # CN=Amazon Root CA 3,O=Amazon,C=US # CN=Amazon Root CA 4,O=Amazon,C=US # CN=Atos TrustedRoot 2011,O=Atos,C=DE # CN=Atos TrustedRoot Root CA ECC TLS 2021,O=Atos,C=DE # CN=Atos TrustedRoot Root CA RSA TLS 2021,O=Atos,C=DE # CN=Autoridad de Certificacion Firmaprofesional CIF A62634068,C=ES # CN=BJCA Global Root CA1,O=BEIJING CERTIFICATE AUTHORITY,C=CN # CN=BJCA Global Root CA2,O=BEIJING CERTIFICATE AUTHORITY,C=CN # CN=Baltimore CyberTrust Root,OU=CyberTrust,O=Baltimore,C=IE # CN=Buypass Class 2 Root CA,O=Buypass AS-983163327,C=NO # CN=Buypass Class 3 Root CA,O=Buypass AS-983163327,C=NO # CN=CA Disig Root R2,O=Disig a.s.,L=Bratislava,C=SK # CN=CFCA EV ROOT,O=China Financial Certification Authority,C=CN # CN=COMODO Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB # CN=COMODO ECC Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB # CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB # CN=Certainly Root E1,O=Certainly,C=US # CN=Certainly Root R1,O=Certainly,C=US # CN=Certigna Root CA,OU=0002 48146308100036,O=Dhimyotis,C=FR # CN=Certigna,O=Dhimyotis,C=FR # CN=Certum EC-384 CA,OU=Certum Certification Authority,O=Asseco Data Systems S.A.,C=PL ...MANY MANY MORE... # SERIALNUMBER=G63287510,CN=ANF Secure Server Root CA,OU=ANF CA Raiz,O=ANF Autoridad de Certificacion,C=ES My problem with this is that this adds a bunch of X.509 CA certificates to a Debian package, and it is unclear for what these are used and trusted for. I'm not sure there is any Debian-wide policy on CA trust anchors -- is there? -- but I think embedding trust anchors like this smells. It would be useful to: 1) Analyze which CA certificates these are, and if it adds anything beyond what we already trust in the "ca-certificates" package. 2) Research for which situations these "fallback" CAs are used. Are they always used for trusting remote sites? Can any of these private-key owner man-in-the-middle any Go TLS session in trixie? 3) If used, document some way for users to disable use of these trust anchors for trust purposes. Either a all-or-nothing switch or some fine-grained mechanism to enable/disable individual CAs. 4) Consider dropping all of these hard coded trust anchors from this package, so that Debian Go applications fall back on the system X.509 CA store instead of using these hard coded trust anchors. This could trigger bugs related to use of system X.509 CA store for Go tools, which I consider a good thing so we catch which tools aren't using system X.509 CA store properly. Thoughts? Cc to debian-go for wider discussion, I hope this has been discussed before so pointers are appreciated, so maybe this is all intentional and no real bug. Maybe there has been discussions with upstream about this? /Simon
Attachment:
signature.asc
Description: PGP signature