Le lun. 1 sept. 2025 à 15:13, Simon Josefsson <[email protected]> a écrit :
> Package: golang-golang-x-crypto-dev > X-Debbugs-CC: [email protected] > > 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. > Not sure if there is a specific policy, avoiding duplication is part of debian policy, so it should be considered a bug not to depend on ca-certificates, in this case. > > 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? > As with other debian packages, this package should *recommend* and use ca-certificates, instead of the upstream bundle of CAs. Usually the discussion with upstream is about enabling a configuration flag that allows one to specify a default vendor (from upstream point of view) path for certificates at build time. > 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 >
