Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
Hi Michael, On Fri, 2020-06-12 at 08:21 -0500, Michael Shuler wrote: > > On 6/12/20 7:36 AM, Adrian Bunk wrote: > > On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote: [...] > > > > Wouldn't embedded setups be more likely to have a hard-coded > > > configuration? > > > > The official way to hardcode CA configuration would be through > > debconf or /etc/ca-certificates.conf, which runs into #743339. > > > > If you are really security-focussed you might pin the actual > > certificate instead of trusing a CA. Sadly that doesn't seem to work with a lot of tools these days. > > For the average embedded device the only thing that matters about > > ca-certificates is something like "https works". > > > > > > Would it work to force-enable them in /etc/ca-certificates.conf > > > > from the preinst when upgrading from old-version matching > > > > 20200601* ? > > > > This could actually be done in the postinst before the debconf > > configuration, something like > >sed -i > > "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt > > |" /etc/ca-certificates.conf > > for all affected certificates when $2 matches 20200601* > > This is what I was working on last night, there is an old dpkg > --compare-versions example in postinst, and that is similar to the > action I had in mind. I intend to sed all in the list we > blacklisted, since they remain in the bundle, so we're not here next > week with another of the date or intermediate exceptions in NSS. If > there is objection to this, please let me know. > > > > I'll leave the technical answer to Michael. > > > > > > Practically, it's then not great for users who had intentionally > > > removed the certificates - or simply decided not to trust them in > > > the first place - prior to the upgrade. I'm not sure how we could > > > distinguish the cases automatically. > > > > The default is to trust all new certificates, so this is what the > > vast majority of users are using. > > > > #743339 is primarily about this kind of remove+readd in the package > > being the only way how any installed certificate could end up being > > deactivated in the default situation. > > > > This is permanent damage that can lead to nasty problems months or > > years later. > > > > There are likely some users somewhere who have manually activated > > or deactivated these specific certificates, but this is nothing we > > can handle correctly in both directions now. > > This is exactly the kind of behavior I think we'd like to preserve, > so we don't stomp on a previous intentional trust setting and > blindly enable, but I think this specific list of blacklisted certs > being re-enabled, if specifically 20200601* is installed should work. > The default "yes" trust and re-enable of these may be the "good > enough" fix, while #743339 is still an issue. That should hit way > over 80% use case, if we consider an 80/20 split. > > For what it's worth, with additional testing after this, I believe I > may have found one of the "save but disable' causes of #743339, > after staring at ca-certificates.conf creation, upgrades, etc in > postinst and the debconf ca-certificates.config contents. It won't > fix existing trust ^!'s, but would help on future root removals - > later on that bug.. > > > > > Unrelated to that, please keep the Python 2 -> 3 build > > > > dependency > > > > change out of this emergency update. > > > > > > ACK. > > Will do, thank you both. How are things looking with the new update? Regards, Adam
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On 6/12/20 7:36 AM, Adrian Bunk wrote: On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote: On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote: Control: tags 962669 moreinfo On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: On 6/11/20 1:33 PM, Adam D. Barratt wrote: Just to confirm - will the certificates be automatically re- added (assuming that users have either the automatically trust or prompt options enabled)? (stretch-pu report cc'ed, since same applies) Excellent question. I believe we're going to hit #743339 "Previously removed certificates not added again". I had not found a reasonable fix for that case in general, to preserve a user's selections. Maybe a "good enough" fix will have to do for the specific ones added back. OK. In that case, how does this seem as an SUA text? [...] use the affected certificates, you may need to manually enable them by running "dpkg-reconfigure ca-certificates" as root. This does not work in various embedded scenarios. Wouldn't embedded setups be more likely to have a hard-coded configuration? The official way to hardcode CA configuration would be through debconf or /etc/ca-certificates.conf, which runs into #743339. If you are really security-focussed you might pin the actual certificate instead of trusing a CA. For the average embedded device the only thing that matters about ca-certificates is something like "https works". Would it work to force-enable them in /etc/ca-certificates.conf from the preinst when upgrading from old-version matching 20200601* ? This could actually be done in the postinst before the debconf configuration, something like sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" /etc/ca-certificates.conf for all affected certificates when $2 matches 20200601* This is what I was working on last night, there is an old dpkg --compare-versions example in postinst, and that is similar to the action I had in mind. I intend to sed all in the list we blacklisted, since they remain in the bundle, so we're not here next week with another of the date or intermediate exceptions in NSS. If there is objection to this, please let me know. I'll leave the technical answer to Michael. Practically, it's then not great for users who had intentionally removed the certificates - or simply decided not to trust them in the first place - prior to the upgrade. I'm not sure how we could distinguish the cases automatically. The default is to trust all new certificates, so this is what the vast majority of users are using. #743339 is primarily about this kind of remove+readd in the package being the only way how any installed certificate could end up being deactivated in the default situation. This is permanent damage that can lead to nasty problems months or years later. There are likely some users somewhere who have manually activated or deactivated these specific certificates, but this is nothing we can handle correctly in both directions now. This is exactly the kind of behavior I think we'd like to preserve, so we don't stomp on a previous intentional trust setting and blindly enable, but I think this specific list of blacklisted certs being re-enabled, if specifically 20200601* is installed should work. The default "yes" trust and re-enable of these may be the "good enough" fix, while #743339 is still an issue. That should hit way over 80% use case, if we consider an 80/20 split. For what it's worth, with additional testing after this, I believe I may have found one of the "save but disable' causes of #743339, after staring at ca-certificates.conf creation, upgrades, etc in postinst and the debconf ca-certificates.config contents. It won't fix existing trust ^!'s, but would help on future root removals - later on that bug.. Unrelated to that, please keep the Python 2 -> 3 build dependency change out of this emergency update. ACK. Will do, thank you both. Kind regards, Michael
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote: > On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote: > > Control: tags 962669 moreinfo > > > > On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: > > > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: > > > > On 6/11/20 1:33 PM, Adam D. Barratt wrote: > > > > > Just to confirm - will the certificates be automatically re- > > > > > added (assuming that users have either the automatically trust > > > > > or prompt options enabled)? > > > > > > > > (stretch-pu report cc'ed, since same applies) > > > > > > > > Excellent question. I believe we're going to hit #743339 > > > > "Previously removed certificates not added again". I had not > > > > found a reasonable fix for that case in general, to preserve a > > > > user's selections. > > > > Maybe a "good enough" fix will have to do for the specific ones > > > > added back. > > > > > > OK. > > > > > > In that case, how does this seem as an SUA text? > [...] > > > use the affected certificates, you may need to manually enable them > > > by running "dpkg-reconfigure ca-certificates" as root. > > > > > > > This does not work in various embedded scenarios. > > Wouldn't embedded setups be more likely to have a hard-coded > configuration? The official way to hardcode CA configuration would be through debconf or /etc/ca-certificates.conf, which runs into #743339. If you are really security-focussed you might pin the actual certificate instead of trusing a CA. For the average embedded device the only thing that matters about ca-certificates is something like "https works". > > Would it work to force-enable them in /etc/ca-certificates.conf > > from the preinst when upgrading from old-version matching 20200601* ? This could actually be done in the postinst before the debconf configuration, something like sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" /etc/ca-certificates.conf for all affected certificates when $2 matches 20200601* > I'll leave the technical answer to Michael. > > Practically, it's then not great for users who had intentionally > removed the certificates - or simply decided not to trust them in the > first place - prior to the upgrade. I'm not sure how we could > distinguish the cases automatically. The default is to trust all new certificates, so this is what the vast majority of users are using. #743339 is primarily about this kind of remove+readd in the package being the only way how any installed certificate could end up being deactivated in the default situation. This is permanent damage that can lead to nasty problems months or years later. There are likely some users somewhere who have manually activated or deactivated these specific certificates, but this is nothing we can handle correctly in both directions now. > > Unrelated to that, please keep the Python 2 -> 3 build dependency > > change out of this emergency update. > > ACK. > > Regards, > > Adam cu Adrian
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote: > Control: tags 962669 moreinfo > > On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: > > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: > > > On 6/11/20 1:33 PM, Adam D. Barratt wrote: > > > > Just to confirm - will the certificates be automatically re- > > > > added (assuming that users have either the automatically trust > > > > or prompt options enabled)? > > > > > > (stretch-pu report cc'ed, since same applies) > > > > > > Excellent question. I believe we're going to hit #743339 > > > "Previously removed certificates not added again". I had not > > > found a reasonable fix for that case in general, to preserve a > > > user's selections. > > > Maybe a "good enough" fix will have to do for the specific ones > > > added back. > > > > OK. > > > > In that case, how does this seem as an SUA text? [...] > > use the affected certificates, you may need to manually enable them > > by running "dpkg-reconfigure ca-certificates" as root. > > > > This does not work in various embedded scenarios. Wouldn't embedded setups be more likely to have a hard-coded configuration? > Would it work to force-enable them in /etc/ca-certificates.conf > from the preinst when upgrading from old-version matching 20200601* ? I'll leave the technical answer to Michael. Practically, it's then not great for users who had intentionally removed the certificates - or simply decided not to trust them in the first place - prior to the upgrade. I'm not sure how we could distinguish the cases automatically. > Unrelated to that, please keep the Python 2 -> 3 build dependency > change out of this emergency update. ACK. Regards, Adam
Bug#962674: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
Control: tags 962669 moreinfo On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote: > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: > > On 6/11/20 1:33 PM, Adam D. Barratt wrote: > > > Just to confirm - will the certificates be automatically re-added > > > (assuming that users have either the automatically trust or prompt > > > options enabled)? > > > > (stretch-pu report cc'ed, since same applies) > > > > Excellent question. I believe we're going to hit #743339 "Previously > > removed certificates not added again". I had not found a reasonable > > fix for that case in general, to preserve a user's selections. Maybe > > a "good enough" fix will have to do for the specific ones added back. > > OK. > > In that case, how does this seem as an SUA text? > > > The ca-certificates update described in SUA 182-1 removed some > certificates issued by Symantec (under various brand names). > Unfortunately, this removal led to a number of reported regressions. > The affected certificates have therefore been reintroduced. > > If you have already installed the package from SUA 182-1, and need to > use the affected certificates, you may need to manually enable them by > running "dpkg-reconfigure ca-certificates" as root. > This does not work in various embedded scenarios. Would it work to force-enable them in /etc/ca-certificates.conf from the preinst when upgrading from old-version matching 20200601* ? Unrelated to that, please keep the Python 2 -> 3 build dependency change out of this emergency update. > Regards, > > Adam cu Adrian
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote: > On 6/11/20 1:33 PM, Adam D. Barratt wrote: > > Just to confirm - will the certificates be automatically re-added > > (assuming that users have either the automatically trust or prompt > > options enabled)? > > (stretch-pu report cc'ed, since same applies) > > Excellent question. I believe we're going to hit #743339 "Previously > removed certificates not added again". I had not found a reasonable > fix for that case in general, to preserve a user's selections. Maybe > a "good enough" fix will have to do for the specific ones added back. OK. In that case, how does this seem as an SUA text? The ca-certificates update described in SUA 182-1 removed some certificates issued by Symantec (under various brand names). Unfortunately, this removal led to a number of reported regressions. The affected certificates have therefore been reintroduced. If you have already installed the package from SUA 182-1, and need to use the affected certificates, you may need to manually enable them by running "dpkg-reconfigure ca-certificates" as root. Regards, Adam
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On 6/11/20 1:33 PM, Adam D. Barratt wrote: Just to confirm - will the certificates be automatically re-added (assuming that users have either the automatically trust or prompt options enabled)? (stretch-pu report cc'ed, since same applies) Excellent question. I believe we're going to hit #743339 "Previously removed certificates not added again". I had not found a reasonable fix for that case in general, to preserve a user's selections. Maybe a "good enough" fix will have to do for the specific ones added back. Thanks for the question, patch ideas welcomed. Michael
Processed: Re: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
Processing control commands: > tags -1 + confirmed Bug #962672 [release.debian.org] buster-pu: package ca-certificates/20200611~deb10u1 Added tag(s) confirmed. -- 962672: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962672 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
Control: tags -1 + confirmed On Thu, 2020-06-11 at 13:25 -0500, Michael Shuler wrote: > #911289 resulted in a regression, and the explicitly blacklisted > roots have been reverted. One in particular, "GeoTrust Global CA", > has caused serious issues noted in #962596. The other reverted roots > also remain in the Mozilla CA bundle[0], so #911289 will require > additional research and be re-opened when uploaded. Please feel free to get the new version uploaded. (It will need to be in unstable before we push it to -updates, but they could be uploaded at the same time.) Just to confirm - will the certificates be automatically re-added (assuming that users have either the automatically trust or prompt options enabled)? Regards, Adam
Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi release team,
#911289 resulted in a regression, and the explicitly blacklisted roots
have been reverted. One in particular, "GeoTrust Global CA", has caused
serious issues noted in #962596. The other reverted roots also remain in
the Mozilla CA bundle[0], so #911289 will require additional research
and be re-opened when uploaded.
buster-proposed-updates and buster-updates both got the previous upload.
I would like to upload ca-certificates_20200611~deb10u1 with the
following changes:
ca-certificates (20200611~deb10u1) buster; urgency=medium
* Rebuild for buster.
* This stable release Closes: #962596, #942915
-- Michael Shuler Thu, 11 Jun 2020 09:07:27
-0500
ca-certificates (20200611) unstable; urgency=medium
* mozilla/blacklist:
Revert Symantec CA blacklist (#911289). Closes: #962596
The following root certificates were added back (+):
+ "GeoTrust Global CA"
+ "GeoTrust Primary Certification Authority"
+ "GeoTrust Primary Certification Authority - G2"
+ "GeoTrust Primary Certification Authority - G3"
+ "GeoTrust Universal CA"
+ "thawte Primary Root CA"
+ "thawte Primary Root CA - G2"
+ "thawte Primary Root CA - G3"
+ "VeriSign Class 3 Public Primary Certification Authority - G4"
+ "VeriSign Class 3 Public Primary Certification Authority - G5"
+ "VeriSign Universal Root Certification Authority"
[ Gianfranco Costamagna ]
* debian/{rules,control}:
Merge Ubuntu patch from Matthias Klose to use Python3 during build.
Closes: #942915
-- Michael Shuler Thu, 11 Jun 2020 08:38:00
-0500
Source debdiff attached.
ca-certificates_20200611~deb10u1 uploaded to mentors[1], RFS will be
submitted pending pu approval. Source can be fetched from mentors or the
`debian-buster` git branch, commit 442fd47f4831483b72329e0df1f6260e4a91ab36.
Binary debdiff files list matches unstable upload for 20200611 currently
on mentors - RFS: #962669.
[0]
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
[1] https://mentors.debian.net/package/ca-certificates
Kind regards,
Michael
diffstat for ca-certificates-20200601~deb10u1 ca-certificates-20200611~deb10u1
debian/changelog| 34 +++---
debian/control |2 +-
mozilla/Makefile|2 +-
mozilla/blacklist.txt | 23 ---
mozilla/certdata2pem.py |2 +-
5 files changed, 30 insertions(+), 33 deletions(-)
diff -Nru ca-certificates-20200601~deb10u1/debian/changelog
ca-certificates-20200611~deb10u1/debian/changelog
--- ca-certificates-20200601~deb10u1/debian/changelog 2020-06-03
13:09:34.0 -0500
+++ ca-certificates-20200611~deb10u1/debian/changelog 2020-06-11
09:07:27.0 -0500
@@ -1,13 +1,33 @@
-ca-certificates (20200601~deb10u1) buster; urgency=medium
+ca-certificates (20200611~deb10u1) buster; urgency=medium
* Rebuild for buster.
- * Merge changes from 20200601
-- d/control; set d/gbp.conf branch to debian-buster
- * This release updates the Mozilla CA bundle to 2.40, blacklists
-distrusted Symantec roots, and blacklists expired "AddTrust External
-Root". Closes: #956411, #955038, #911289, #961907
+ * This stable release Closes: #962596, #942915
- -- Michael Shuler Wed, 03 Jun 2020 13:09:34 -0500
+ -- Michael Shuler Thu, 11 Jun 2020 09:07:27 -0500
+
+ca-certificates (20200611) unstable; urgency=medium
+
+ * mozilla/blacklist:
+Revert Symantec CA blacklist (#911289). Closes: #962596
+The following root certificates were added back (+):
++ "GeoTrust Global CA"
++ "GeoTrust Primary Certification Authority"
++ "GeoTrust Primary Certification Authority - G2"
++ "GeoTrust Primary Certification Authority - G3"
++ "GeoTrust Universal CA"
++ "thawte Primary Root CA"
++ "thawte Primary Root CA - G2"
++ "thawte Primary Root CA - G3"
++ "VeriSign Class 3 Public Primary Certification Authority - G4"
++ "VeriSign Class 3 Public Primary Certification Authority - G5"
++ "VeriSign Universal Root Certification Authority"
+
+ [ Gianfranco Costamagna ]
+ * debian/{rules,control}:
+Merge Ubuntu patch from Matthias Klose to use Python3 during build.
+Closes: #942915
+
+ -- Michael Shuler Thu, 11 Jun 2020 08:38:00 -0500
ca-certificates (20200601) unstable; urgency=medium
diff -Nru ca-certificates-20200601~deb10u1/debian/control
ca-certificates-20200611~deb10u1/debian/control
--- ca-certificates-20200601~deb10u1/debian/control 2020-06-03
13:09:34.0 -0500
+++ ca-certificates-20200611~deb10u1/debian/control 2020-06-11
09:07:27.0 -0500
@@ -5,7 +5,7 @@
Uploaders: Raphael Geissert ,
Thijs Kinkhorst
Build-Depends: debhelper-compat (= 12), po-debconf
-Build-Depends-Indep: python, openssl
+Build-Depends-Indep: python3, openssl
