Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64)
This audio issue was resolved for me with the SoC updates included in stable linux-image: 5.10.0-21-amd64 5.10.162-1 (2023-01-21) x86_64 For reference, my machine info: Product Name: 20QDCTO1WW Version: ThinkPad X1 Carbon 7th BIOS Version: N2HET68W (1.51) Audio PCI info: 00:1f.3 Audio device [0403]: Intel Corporation Cannon Point-LP High Definition Audio Controller [8086:9dc8] (rev 11) (prog-if 80) Thanks for this bug report, the build info and revert patch for -20, and for rolling in the additional SoC bits to make -21 work properly. Kind regards, Michael
Bug#996005: ca-certificates: fails upgrading when no new certs selected
On 10/9/21 6:40 PM, Christoph Anton Mitterer wrote: It seems that when not selecting any of the new certs on upgrade, the package install fails: Setting up ca-certificates (20211004) ... Updating certificates in /etc/ssl/certs... chmod: cannot access '/etc/ssl/certs/ca-certificates.crt.new': No such file or directory dpkg: error processing package ca-certificates (--configure): installed ca-certificates package post-installation script subprocess returned error exit status 1 Good find - patch attached to check if file exists before chmod & mv. -- Kind regards, Michael diff --git a/debian/changelog b/debian/changelog index 2a146c2..7b1e0bc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +ca-certificates (20211010) UNRELEASED; urgency=medium + + [ Michael Shuler ] + * Fix error on install when TEMPBUNDLE missing. Closes: #996005 + + -- Michael Shuler Sun, 10 Oct 2021 09:10:28 -0500 + ca-certificates (20211004) unstable; urgency=low [ Debian Janitor ] diff --git a/sbin/update-ca-certificates b/sbin/update-ca-certificates index 789867f..0265205 100755 --- a/sbin/update-ca-certificates +++ b/sbin/update-ca-certificates @@ -187,8 +187,12 @@ then fi fi -chmod 0644 "$TEMPBUNDLE" -mv -f "$TEMPBUNDLE" "$CERTBUNDLE" +# chmod and mv only if TEMPBUNDLE exists or install may fail, #996005 +if [ -f "$TEMPBUNDLE" ] +then + chmod 0644 "$TEMPBUNDLE" + mv -f "$TEMPBUNDLE" "$CERTBUNDLE" +fi # Restore proper SELinux label after moving the file [ -x /sbin/restorecon ] && /sbin/restorecon "$CERTBUNDLE" >/dev/null 2>&1
Bug#992300: ca-certificates: ca-certificate update fails because of missing /usr/bin/cert-sync
On 8/17/21 9:40 AM, Alex wrote: I am not sure if ca-certificates-mono was installed at all. I do not have mono on the system. The machine did have the packages below installed at some point. $ dpkg -l|grep mono|grep -v fonts-|grep -v python3-monotonic rc ca-certificates-mono 4.6.2.7+dfsg-1 all Common CA certificates (Mono keystore) rc mono-runtime-common 4.6.2.7+dfsg-1 amd64Mono runtime - common files The packages were removed (r), leaving behind configuration (c) files. $ ls /etc/ca-certificates/update.d/mono-keystore /usr/bin/cert-sync ls: cannot access '/usr/bin/cert-sync': No such file or directory /etc/ca-certificates/update.d/mono-keystore Version 4.6.2.7+dfsg-1 is listed on p.d.o as the latest version from Stretch, so it could have been quite some time ago and your logs for that were likely rotated, so not in the latest dpkg.log file. Purging packages would also remove configurations, so if you wish to do a little clean up: apt purge ca-certificates-mono mono-runtime-common Seems this bug can likely be closed, the fix version for #902663 is later than the reporter's old "rc" remnants. Kind regards, Michael
Bug#992300: ca-certificates: ca-certificate update fails because of missing /usr/bin/cert-sync
Control: notfound -1 20210119 Control: reassign -1 ca-certificates-mono Control: tags -1 + moreinfo On 8/16/21 4:58 PM, Alex wrote: ... Updating Mono key store /etc/ca-certificates/update.d/mono-keystore: 10: /usr/bin/cert-sync: not found Done Reassigning to appropriate package, ca-certificates-mono. Bug reporter's ca-certificates-mono version is unknown, but it appears that #902663 with the same error report was fixed in ca-certificates-mono 5.18.0.240+dfsg-2. Please, update bug report with the proper "found" version. Kind regards, Michael
Bug#976406: O: ca-certificates -- Common CA certificates
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have orphaned the ca-certificates package, due to time constraints. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: ca-certificates Binary: ca-certificates, ca-certificates-udeb Version: 20190110 Maintainer: Michael Shuler Uploaders: Raphael Geissert , Thijs Kinkhorst Build-Depends: debhelper-compat (= 12), po-debconf Build-Depends-Indep: python, openssl Architecture: all Standards-Version: 4.3.0.1 Format: 3.0 (native) Files: e1b3a61d2ae8fd7bc833e9c4bcae5f13 1805 ca-certificates_20190110.dsc e91d3d9259127ba2dbb65fda58d73f31 243472 ca-certificates_20190110.tar.xz Vcs-Browser: https://salsa.debian.org/debian/ca-certificates Vcs-Git: https://salsa.debian.org/debian/ca-certificates.git Checksums-Sha256: bffbfe63a1ad2a07c6094502f05899c65edba93aefe58682f440e000fc65f6f0 1805 ca-certificates_20190110.dsc ee4bf0f4c6398005f5b5ca4e0b87b82837ac5c3b0280a1cb3a63c47555c3a675 243472 ca-certificates_20190110.tar.xz Package-List: ca-certificates deb misc optional arch=all ca-certificates-udeb udeb debian-installer optional arch=all Directory: pool/main/c/ca-certificates Priority: source Section: misc Package: ca-certificates Version: 20190110 Priority: optional Section: misc Maintainer: Michael Shuler Installed-Size: 393 kB Depends: openssl (>= 1.1.1), debconf (>= 0.5) | debconf-2.0 Breaks: ca-certificates-java (<< 20121112+nmu1) Enhances: openssl Tag: protocol::ssl, role::app-data, security::authentication Download-Size: 157 kB APT-Manual-Installed: no APT-Sources: http://deb.debian.org/debian buster/main i386 Packages Description: Common CA certificates Contains the certificate authorities shipped with Mozilla's browser to allow SSL-based applications to check for the authenticity of SSL connections. . Please note that Debian can neither confirm nor deny whether the certificate authorities whose certificates are included in this package have in any way been audited for trustworthiness or RFC 3647 compliance. Full responsibility to assess them belongs to the local system administrator. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEom5SiycfGbnl2OGeoni3gf5LK9oFAl/KgMcACgkQoni3gf5L K9r3yQ/+KX8VXWAVmF+e/LT9EieilhbGjYcKh+dtRc7hOiMjaiXqjAZhWLCOi/r2 PNUk/L5oxpZUty4rnBsaRbHoKVG2u1VbKIj3sAVgYjGcmi10b86DOWzdAvQO9EZn HezUWImTHWFMp1lSBIhGyS+BzngG7axNGcr7wepOdh6Y4l+3KYYbc+wAF9BpMPVv sT55pa9BhiWZfTTVhhA+Xur2hGgTZAYJgLhiTQV36yRUPc+QpxQVUvhRiXKls1HC 18RT6IRRMRcyLt6hMYbZrEVqteGq/5/iNONJ3DNoRbKzf1dp8T4ANspDMZAItcvV L+G6FgIWDaPJLZBQsFRVYitSSb5kPtyyVPfH3V68PSpHMaDVOdfBz2vqg7h1BYBq M1a1wFoLTJVQo2hpbsoQu6s7gGp+g02uV5IS+ixeMlr0GCZfb6g5SxIrGNhanhG/ dIJikvRfUfkYLrjgAMnNI9moJxpuUX+YIseRglcMJ4i3BiF1va+9081BwQpFaNsO VAJ+tGv1IxVieTMlPZelLXBiL1bbfOkfCWB3OUSZEtgwtuuVJ1Bx1Cc4g981cQUf mXzo8mPaRGGTXJ6uCfQiBHVrNDgI4eSeawUulkcPMcXD1MUwjZlkXG3CCZQRkWke A0M026uv19KLqFxdgyi0mC1O2DCiUJwi0/qgIF+NGtCB1mz8APc= =sNlZ -END PGP SIGNATURE-
Bug#962669: 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 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
Bug#962674: stretch-pu: package ca-certificates/20200611~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
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.
stretch-proposed-updates and stretch-updates both got the previous upload.
I would like to upload ca-certificates_20200611~deb9u1 with the
following changes:
ca-certificates (20200611~deb9u1) stretch; urgency=medium
* Rebuild for stretch.
* This oldstable release Closes: #962596, #942915
-- Michael Shuler Thu, 11 Jun 2020 09:11:56
-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~deb9u1 uploaded to mentors[1], RFS will be
submitted pending pu approval. Source can be fetched from mentors or the
`debian-stretch` git branch, commit
c151326dda72f703f7001f655e331b548eb1e411.
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~deb9u1 ca-certificates-20200611~deb9u1
debian/changelog| 37 +++--
debian/control |8
mozilla/Makefile|2 +-
mozilla/blacklist.txt | 23 ---
mozilla/certdata2pem.py |2 +-
5 files changed, 33 insertions(+), 39 deletions(-)
diff -Nru ca-certificates-20200601~deb9u1/debian/changelog
ca-certificates-20200611~deb9u1/debian/changelog
--- ca-certificates-20200601~deb9u1/debian/changelog2020-06-05
11:52:50.0 -0500
+++ ca-certificates-20200611~deb9u1/debian/changelog2020-06-11
09:11:56.0 -0500
@@ -1,16 +1,33 @@
-ca-certificates (20200601~deb9u1) stretch; urgency=medium
+ca-certificates (20200611~deb9u1) stretch; urgency=medium
* Rebuild for stretch.
- * Merge changes from 20200601
-- d/control
- * 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
- * Fix permissions on /usr/local/share/ca-certificates when using symlinks.
-Closes: #916833
- * Remove email-only roots from mozilla trust store. Closes: #721976
+ * This oldstable release Closes: #962596, #942915
- -- Michael Shuler Fri, 05 Jun 2020 11:52:50 -0500
+ -- Michael Shuler Thu, 11 Jun 2020 09:11:56 -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~deb9u1/debian/control
ca-certificates-20200611~deb9u
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 2
Bug#962669: RFS: ca-certificates/20200611 [RC] -- Common CA certificates
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "ca-certificates"
* Package name: ca-certificates
Version : 20200611
* License : Mozilla Public License Version 2.0
* Vcs : https://salsa.debian.org/debian/ca-certificates
Section : misc
It builds those binary packages:
ca-certificates - Common CA certificates
ca-certificates-udeb - Common CA certificates - udeb
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ca-certificates
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200611.dsc
Changes since the last upload:
* 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
Regards,
--
Michael Shuler
Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation
Control: severity -1 serious Control: tags -1 + pending Control: tags 942915 + pending Bump severity. Pending branch commits: master: commit 679daf6e9bf6fcdcb574b8029297d24836fafde0 Revert "Set release 20200601; add Symantec CAs to blacklist" This reverts commit 1efe81a680eedb94111716c8825290a0cde509af. debian-buster: commit 442fd47f4831483b72329e0df1f6260e4a91ab36 Merge branch 'master' into debian-buster debian-stretch: commit c151326dda72f703f7001f655e331b548eb1e411 Merge branch 'debian-buster' into debian-stretch Kind regards, Michael
Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation
Control: severity -1 important (cc'ed bug reporters and those on a direct email to ack) On 6/10/20 3:27 PM, Carlos Alberto Lopez Perez wrote: On 10/06/2020 16:51, Philippe Normand wrote: Since the update of ca-certificates to version 20200601 I can no longer access webkit.org websites. The removed CA (GeoTrust Global CA) is used to sign the Apple intermediate certificate "Apple IST CA 2 - G1". Firefox and Chrome have some sort of hack (likely a whitelist) specifically to trust this Apple's intermediate CAs: https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec So the website still works in Firefox and Chrome on Debian, even with GeoTrust removed. But it doesn't work with GnuTLS (or the Epiphany web browser). Thanks for the bug report. I will work on reverting the blacklist commit and get with the release team when that is completed. Kind regards, Michael
Bug#962245: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
On 6/5/20 10:35 AM, Adrian Bunk wrote: Except for keeping debian/NEWS you were actually backporting everything that was possible, this was not a 20161130+nmu1+deb9u2 release that cherry-picked only one or few changes. Given the nature of ca-certificates it was IMHO the correct decision to backport as much as possible, it is just not "backporting as little as possible". Since similar updates to stable releases might happen in the future, I would recommend that you try to get build and runtime dependencies in unstable to a level that allows rebuilding the package in all supported Debian releases. For compatibility with buster this would include staying at dh compat <= 12. "Backporting everything possible" changes are often safest when the only change in the ~deb10u1 source package is the entry in debian/changelog. I uploaded an updated package for 20200601~deb9u1 to mentors and updated #962155 for approval. Backporting the latest changes to stable and oldstable was the essence of a conversation on making that simpler with this package. These uploads get us a lot closer. The branch diffs are not far off now. Stretch has an openssl version without `openssl rehash`, but that is not a large diff. Both stretch & buster will have python->python3 difference from unstable on the next release, but that's also not a large diff. I hadn't thought about leaving older compat and standards in unstable, I generally try to keep lintian pleased.. not a bad idea, if no one minds much. Thanks again - I'll update this RFS when #962155 comes back from the release team. Michael
Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1
On 6/5/20 10:37 AM, Adam D. Barratt wrote:
On Thu, 2020-06-04 at 20:48 -0500, Michael Shuler wrote:
Thanks again, uploaded to mentors:
RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
https://bugs.debian.org/962245
I re-uploaded to mentors the updated 20200601~deb9u1 package artifacts
with the suggested changes committed.
I see there was some additional feedback on the RFS, which is why this
hasn't been uploaded yet.
It makes sense to combine the release via stretch-updates and buster-
updates, so we can release a single SUA and users don't have to stagger
updates. On that basis, I'll hold off on that until we have more idea
what's happening with the stretch update.
Yes, Adrian was super helpful with this style of backporting latest.
With that advice, here is the current package debdiff from latest
version, which gets us where we want:
$ debdiff ca-certificates_20200601_all.deb
ca-certificates_20200601~deb9u1_all.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: openssl (>= [-1.1.1),-] {+1.0.0),+} debconf (>= 0.5) | debconf-2.0
Installed-Size: [-381-] {+380+}
Version: [-20200601-] {+20200601~deb9u1+}
Updated changelog adds the removal of email-only roots from stretch:
ca-certificates (20200601~deb9u1) stretch; urgency=medium
* Rebuild for stretch.
* Merge changes from 20200601
- d/control
* 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
* Fix permissions on /usr/local/share/ca-certificates when using
symlinks.
Closes: #916833
* Remove email-only roots from mozilla trust store. Closes: #721976
Attached is the updated debdiff.gz from oldstable->this_backport and
those stats:
diffstat for ca-certificates-20161130+nmu1+deb9u1
ca-certificates-20200601~deb9u1
.gitignore | 12
debian/NEWS | 393 ---
debian/ca-certificates.postinst |8
debian/changelog| 231 +
debian/copyright| 14
mozilla/blacklist.txt | 54
mozilla/certdata.txt| 4927
mozilla/certdata2pem.py |2
mozilla/nssckbi.h |6
9 files changed, 2734 insertions(+), 2913 deletions(-)
----
Kind regards,
Michael Shuler
ca-certificates_20200601~deb9u1.debdiff.gz
Description: application/gzip
Bug#962245: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
On 6/5/20 4:15 AM, Adrian Bunk wrote: Compared to 20200601 and 20200601~deb10u1 this contains the following additional files: /usr/share/ca-certificates/mozilla/AddTrust_Low-Value_Services_Root.crt /usr/share/ca-certificates/mozilla/Camerfirma_Chambers_of_Commerce_Root.crt /usr/share/ca-certificates/mozilla/Camerfirma_Global_Chambersign_Root.crt /usr/share/ca-certificates/mozilla/Certum_Root_CA.crt /usr/share/ca-certificates/mozilla/D-TRUST_Root_CA_3_2013.crt /usr/share/ca-certificates/mozilla/SwissSign_Platinum_CA_-_G2.crt /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.crt /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.crt /usr/share/doc/ca-certificates/NEWS.Debian.gz The additional NEWS.Debian.gz is either correct or harmless, the additional certificates are not. This is due to the backport missing the "Remove email-only roots from mozilla trust store" (#721976) change that is in 20200601. Great catch, thanks, result of using currentver~debXuY as discussed with some people for better update recognition, while backporting as little as possible. I was diffing 20161130+nmu1+deb9u1 to ca-certificates-20200601~deb9u1, so this is also a good check the other direction. I hadn't removed d/NEWS, which was dropped in later versions. I also had not modified certdata2pem.py from the latest. I will take a look at the changes for #721976 and see if it seems ok, I think the email root removal backport is reasonable. Please update the stretch-pu request with that fixed and let me know when the corrected debdiff is approved. Will do, thank you for the feedback. -- Kind regards, Michael
Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1
Thanks again, uploaded to mentors: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates https://bugs.debian.org/962245 -- Kind regards, Michael
Bug#962152: buster-pu: package ca-certificates/20200601~deb10u1
Thank you. Uploaded to mentors: RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates https://bugs.debian.org/962244 -- Kind regards, Michael
Bug#962245: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
Package: sponsorship-requests Severity: important Dear mentors, ** stretch-pu approval and debdiff can be found on: https://bugs.debian.org/962155 I am looking for a sponsor for my package "ca-certificates" * Package name: ca-certificates Version : 20200601~deb9u1 * License : Mozilla Public License Version 2.0 * Vcs : https://salsa.debian.org/debian/ca-certificates (debian-stretch branch) Section : misc It builds those binary packages: ca-certificates - Common CA certificates ca-certificates-udeb - Common CA certificates - udeb To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ca-certificates Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb9u1.dsc Changes since the last upload: * Rebuild for stretch. * Merge changes from 20200601 - d/control * 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 * Fix permissions on /usr/local/share/ca-certificates when using symlinks. Closes: #916833 Thank you sponsor! -- Kind regards, Michael Shuler
Bug#962244: RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates
Package: sponsorship-requests Severity: important Dear mentors, ** buster-pu approval and debdiff can be found on: https://bugs.debian.org/962152 I am looking for a sponsor for my package "ca-certificates" * Package name: ca-certificates Version : 20200601~deb10u1 * License : Mozilla Public License Version 2.0 * Vcs : https://salsa.debian.org/debian/ca-certificates (debian-buster branch) Section : misc It builds those binary packages: ca-certificates - Common CA certificates ca-certificates-udeb - Common CA certificates - udeb To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ca-certificates Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb10u1.dsc Changes since the last upload: * 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 Thank you sponsor! -- Kind regards, Michael Shuler
Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu * Note: Please, upload this to stretch-updates as well to fix ongoing issues with failing web services from the expired AddTrust certificate. See #961907 for details. I would like to upload ca-certificates_20200601~deb9u1 with the following fixes: ca-certificates (20200601~deb9u1) stretch; urgency=medium * Rebuild for stretch. * Merge changes from 20200601 - d/control * 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 * Fix permissions on /usr/local/share/ca-certificates when using symlinks. Closes: #916833 diffstat for ca-certificates-20161130+nmu1+deb9u1 ca-certificates-20200601~deb9u1 .gitignore | 12 debian/ca-certificates.postinst |8 debian/changelog| 228 + debian/copyright| 14 mozilla/blacklist.txt | 54 mozilla/certdata.txt| 4927 mozilla/nssckbi.h |6 7 files changed, 2731 insertions(+), 2518 deletions(-) Full debdiff.gz attached, due to the size of certdata changes. -- Kind regards, Michael Shuler ca-certificates_20200601~deb9u1.debdiff.gz Description: application/gzip
Bug#962152: buster-pu: package ca-certificates/20200601~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu * Note: Please, upload this to buster-updates as well to fix ongoing issues with failing web services from the expired AddTrust certificate. See #961907 for details. I would like to upload ca-certificates_20200601~deb10u1 with the following fixes: ca-certificates (20200601~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 diffstat for ca-certificates-20190110 ca-certificates-20200601~deb10u1 debian/changelog | 59 debian/copyright | 12 debian/gbp.conf |2 mozilla/blacklist.txt | 26 mozilla/certdata.txt | 3908 -- mozilla/nssckbi.h |4 6 files changed, 2318 insertions(+), 1693 deletions(-) Full debdiff.gz attached, due to the size of certdata changes. -- Kind regards, Michael ca-certificates_20200601~deb10u1.debdiff.gz Description: application/gzip
Bug#942915: ca-certificates: Python2 removal in sid/bullseye
tags 942915 + pending thanks On 6/3/20 6:25 AM, Gianfranco Costamagna wrote: the patch is now committed on the shared git, but I don't plan to upload it. (I don't like to touch native packages when possible) I was just looking at this exact change last night, thanks for the commit. It wasn't clear to me that python3 could be expected to be installed on a minimal unstable OS, since the python wiki page lists, "Debian Unstable contains some 2.x and 3.x, python2 is being removed". Works for me to include in unstable, since the python2 removal is on the way, but may result in a little fallout until removal is completed. Kind regards, Michael
Bug#962008: RFS: ca-certificates/20200601 [RC] -- Common CA certificates
On 6/3/20 1:37 AM, Adrian Bunk wrote: ca-certificates (20200601) unstable; urgency=medium ca-certificates (20200601~deb10u1) buster-security; urgency=medium ca-certificates (20200601~deb9u1) stretch-security; urgency=medium Did you already agree with the security team (Cc'ed) that these should also be published as DSA for stable and oldstable? If yes, a security team member might be the best person to sponsor these for unstable/buster-security/stretch-security. If they shouldn't be treated as DSA, the uploads for stable and oldstable have to be done differently. BTW: What is the next expiry date of any certificate in ca-certificates? (Note: 20200601 has been uploaded to unstable by Andrew Shadura - thank you for the upload, Andrew.) Re: exipry dates: Generally, expiry date has not been an issue remaining in the bundle until removal upstream, since the certification authorities have managed migration to new roots well and openssl>=1.1.1 handles this gracefully. This appears to have not been the case with AddTrust and older openssl<1.1.1 bug, as that fix was not backported, to the best of my understanding. I would have to cycle through all the certs to see what dates are upcoming, but this is a new(old-openssl) problem, apparently. I don't have that bit of time at this very moment. Re: security uploads: I have received no reply from the security team, as of this message, so awaiting their OK/advice. Copy of email sent to team@security, since there is no secret info in here: Forwarded Message Subject: ca-certificates: buster-security & stretch-security (and sid) uploads Date: Mon, 1 Jun 2020 22:22:47 -0500 From: Michael Shuler To: t...@security.debian.org Hi Security Team, I committed changes to to git for an RC security issue, as well as update the certificate bundle to current. This has been critical for a number of web services failing due to the expired certificate on older operating systems. Evidently this has been fixed in openssl-1.1.1, but never backported. I have prepared unstable, and stable/oldstable security updates on mentors. https://salsa.debian.org/debian/ca-certificates/ master sha for unstable (ca-certificates_20200601): b3a8980b · Fix typo on AddTrust CN RC bug fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961907 CA update: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955038 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956411 Symantec roots explicitly blacklisted: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911289 The master branch was merged to the debian-buster and debian-stretch branches (control file kept) and releases created for buster-security and stretch-security debian-buster sha (ca-certificates_20200601~deb10u1): 5256b350 · Set buster-security for suite debian-stretch sha (ca-certificates_20200601~deb10u1): 7bd8f941 · Set stretch-security for suite I uploaded all 3 to mentors and they are ready to be sponsored: https://mentors.debian.net/package/ca-certificates bug#s for the mentors upload requests: unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962008 buster-security: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962009 stretch-security: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962010 Please, let me know if I can provide any additional info. Kind regards, Michael
Bug#962079: Blacklist Expired Certificate: CN=Staat der Nederlanden Root CA - G2
Package: ca-certificates Version: 20200601 Severity: normal Follow up to #955038, expired certificate "Staat der Nederlanden Root CA - G2" remains in the Mozilla bundle. If the CA managed their migration to the same-named G3 cert, this could be a non-issue, however the expired certificate can be blacklisted to effectively remove it. CCing #955038 (remove in later replies, please) and BCCing the original and secondary reporters to acknowledge. Thanks for report and follow up on the error. Kind regards, Michael Shuler -- $ openssl x509 -noout -startdate -enddate -in /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_Root_CA_-_G2.crt notBefore=Mar 26 11:18:17 2008 GMT notAfter=Mar 25 11:03:10 2020 GMT $ openssl x509 -noout -startdate -enddate -in /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_Root_CA_-_G3.crt notBefore=Nov 14 11:28:42 2013 GMT notAfter=Nov 13 23:00:00 2028 GMT
Bug#962010: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ca-certificates" * Package name: ca-certificates Version : 20200601~deb9u1 * License : Mozilla Public License Version 2.0 * Vcs : https://salsa.debian.org/debian/ca-certificates Section : misc It builds those binary packages: ca-certificates - Common CA certificates ca-certificates-udeb - Common CA certificates - udeb To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ca-certificates Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb9u1.dsc Changes since the last upload: * Rebuild for stretch-security. * Merge changes from 20200601 - d/control * This security release updates the Mozilla CA bundle and blacklists distrusted Symantec roots and the expired AddTrust External Root. Regards, Michael Shuler
Bug#962009: RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ca-certificates" * Package name: ca-certificates Version : 20200601~deb10u1 * License : Mozilla Public License Version 2.0 * Vcs : https://salsa.debian.org/debian/ca-certificates Section : misc It builds those binary packages: ca-certificates - Common CA certificates ca-certificates-udeb - Common CA certificates - udeb To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ca-certificates Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601~deb10u1.dsc Changes since the last upload: * Rebuild for buster-security. * Merge changes from 20200601 - d/control; set d/gbp.conf branch to debian-buster * This security release updates the Mozilla CA bundle and blacklists distrusted Symantec roots and the expired AddTrust External Root. Regards, Michael Shuler
Bug#962008: RFS: ca-certificates/20200601 [RC] -- Common CA certificates
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "ca-certificates"
* Package name: ca-certificates
Version : 20200601
* License : Mozilla Public License Version 2.0
* Vcs : https://salsa.debian.org/debian/ca-certificates
Section : misc
It builds those binary packages:
ca-certificates - Common CA certificates
ca-certificates-udeb - Common CA certificates - udeb
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ca-certificates
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20200601.dsc
Changes since the last upload:
* debian/control:
Set Standards-Version: 4.5.0.2
Set Build-Depends: debhelper-compat (= 13)
* debian/copyright:
Replace tabs in license text
* mozilla/{certdata.txt,nssckbi.h}:
Update Mozilla certificate authority bundle to version 2.40.
Closes: #956411, #955038
* mozilla/blacklist.txt
Add distrusted Symantec CA list to blacklist for explicit removal.
Closes: #911289
Blacklist expired root certificate, "AddTrust External Root"
Closes: #961907
The following certificate authorities were added (+):
+ "Certigna Root CA"
+ "emSign ECC Root CA - C3"
+ "emSign ECC Root CA - G3"
+ "emSign Root CA - C1"
+ "emSign Root CA - G1"
+ "Entrust Root Certification Authority - G4"
+ "GTS Root R1"
+ "GTS Root R2"
+ "GTS Root R3"
+ "GTS Root R4"
+ "Hongkong Post Root CA 3"
+ "UCA Extended Validation Root"
+ "UCA Global G2 Root"
The following certificate authorities were removed (-):
- "AddTrust External Root"
- "Certinomis - Root CA"
- "Certplus Class 2 Primary CA"
- "Deutsche Telekom Root CA 2"
- "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"
Regards,
Michael Shuler
Bug#911289: Tagging Pending Bugs
tags 911289 + pending tags 955038 + pending tags 956411 + pending tags 961907 + pending thanks This commit on master is good to go to fix the above bugs in unstable - marking them pending: commit b3a8980b781bc9a370e42714a605cd4191bb6c0b Commit: Michael Shuler CommitDate: Mon Jun 1 14:38:12 2020 -0500 Fix typo on AddTrust CN Looking at stable, oldstable builds using the same commit, next. Likely standards/compat need downgrading, but should work ok as-is otherwise. CCing Thijs and a few others directly for upload, or I can go the mentors route. Thank you, sponsor! -- Kind regards, Michael
Bug#956411: ca-certificates: please update to latest Mozilla bundle
Thanks for the bug report. I've checked in the latest release branch certdata, so the recent adds/removes will be up in the next release. I'll try to get that release built soon, it has indeed been a while. Kind regards, Michael
Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)
On 2/5/20 11:12 AM, Dan Nicholson wrote: I recently ran into this same issue and dug into it for a while. The real problem stems from https://sourceware.org/bugzilla/show_bug.cgi?id=23960. The issue is that glibc 2.28 changed readdir to always use getdents64. This causes problems when you're running a 32 bit guest in QEMU on a 64 bit host. So, this would also affect running an i386 guest on an x86_64 host, for example. Thanks for the details. This appears more to me now that this is a lower level issue than the symptomatic behavior we see in processing certificates. (ie. this is not a bug with ca-certificates, but with openssl) So, I think there are a few options on what to do. 1. Change update-ca-certificates back to using c_rehash. Presumably perl is built with LFS and it's readdir wrapper DTRT. c_rehash could be removed at any time, so I don't think this is a good option. 2. Build openssl with LFS as noted above. Noted, thanks. This is why I am starting to believe this is a bug with openssl, not ca-certificates. 3. Wait for a fix to be hashed out between the glibc, kernel and qemu folks. ..which I suppose is indeed the eventual lower level issue to resolve, below openssl. -- Kind regards, Michael
Bug#927879: ca-certificates should not hardcode QuoVadis certificate authorities in /etc/ca-certificates.conf
On 4/24/19 5:22 PM, Soppy bear wrote: 1. This is a Debian problem because the end user should be able to use TLS without having to import/use certificates without any practical use for normal operations. Users *can* configure the ca-certificate package and set CA trust for each and every CA, as well as configure new-CA trust however they wish. Users can preseed debconf at installation time to trust no CAs, if they so desire. I'm not going to get into the details of preseeding installations, but runtime configuration is done with: dpkg-reconfigure ca-certificates Please, describe the problem better, if there is a concrete bug. The description here and previously make little sense to me, other than a personal preference and misunderstanding of how to configure CA trust. If there is a CA in the current Mozilla bundle that is problematic for you and the Internet, please contact Mozilla with this information, if there is evidence of evil doings, Mozilla is the correct project to inform. If you don't trust a particular CA that is in the current Mozilla bundle, disable it. You can automate this, if you maintain a large number of systems. 2. I have removed Firefox from my systems permanently because of this reason and upgraded my research laptop to debian unstable for this specific reason. OK. What does this have to do with the ca-certificates package? -- Kind regards, Michael
Bug#923942: postinst script error: mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of itself, 'ca-certificates.crt'
On 3/19/19 3:29 AM, Michael Stapelberg wrote: > So I debugged this some more, and found out that the problem is that > moving *any files* from /tmp to /etc does not work, but only within the > Docker container running on travis-ci, and only when configured with > “group: deprecated-2017Q3”. The fix is to remove that config option: > https://github.com/i3/i3/pull/3650. > > I will write this off to kernel weirdness, but, independently of this > issue, it might make sense to change update-ca-certificates to no longer > need /tmp and instead create the temporary files within /etc, which > would get us closer to an atomic replacement. I appreciate the follow up. I did some quick reproduction attempts last weekend, but was unable to get the same behavior, so this makes more sense. There's another recent edge case bug, #923784 (full root partition), that may benefit from using an explicit /etc path with mktmp, so maybe we'll get a 2 for 1 fix. -- Kind regards, Michael
Bug#923784: update-ca-certificates: corrupts ca-certificates.crt on full root file system
On 3/5/19 11:47 AM, Arthur de Jong wrote: > I have created a merge request in Salsa for this: > https://salsa.debian.org/debian/ca-certificates/merge_requests/2 Thank for the MR. I'll take a look. -- Kind regards, Michael
Bug#923942: postinst script error: mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of itself, 'ca-certificates.crt'
On 3/7/19 8:13 AM, Michael Stapelberg wrote: > Package: ca-certificates > Version: 20190110 > Severity: normal > > The i3 continuous integration testing on travis-ci.org currently fails: > > Setting up ca-certificates (20190110) ... > Updating certificates in /etc/ssl/certs... > mv: cannot move '/tmp/ca-certificates.crt.tmp.hi8W7j' to a subdirectory of > itself, 'ca-certificates.crt' > dpkg: error processing package ca-certificates (--configure): > installed ca-certificates package post-installation script subprocess > returned error exit status 1 > > See https://travis-ci.org/i3/i3/jobs/503115864 for the full log. > > Have not dug any deeper, but perhaps this rings a bell, or is obvious from the > error message. Let me know if you need more details. Thank you. I have not seen this error before, but will dig around! -- Kind regards, Michael
Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)
On 2/28/19 7:37 PM, James Pooton wrote: > So installing ca-certificates (20170717) with the latest openssl > (1.1.1a-1), does produce the hashes in /etc/ssl/certs when doing an ARM > 32bit build via QEMU. > > One interesting thing is that the 382 syscalls were still present in the > build, so that may be a red herring: > > ... > Preparing to unpack .../ca-certificates_20170717_all.deb ... > Unpacking ca-certificates (20170717) ... > Setting up ca-certificates (20170717) ... > Updating certificates in /etc/ssl/certs... > qemu: Unsupported syscall: 382 > 148 added, 0 removed; done. > Processing triggers for ca-certificates (20170717) ... > Updating certificates in /etc/ssl/certs... > qemu: Unsupported syscall: 382 > 0 added, 0 removed; done. > ... Interesting, thanks. So c_rehash works fine-ish, which we were pretty sure of, and the same behavior with the syscall errors. /usr/bin/c_rehash is perl with a few calls out to openssl within. You could try to debug by directly running `sudo openssl rehash -v /etc/ssl/certs` on either version of ca-certificates (new one has new CAs added, old ones removed, and a couple other bug fixes, but openssl behavior should be the same). > The only other thing I noticed (which certainly may not be related) is > that a a few of the CA cert filename must have some crazy UTF8 > characters that get encoded (“NetLock_Arany”, > “RKTRUST_Elektronik_Sertifika_Hizmet_Sa”, “k_Sertifika_Hizmet_Sa”). > Just seemed odd, and potentially something that could trip things up. Yep, there are a few CAs with UTF8 labels, so the files are written out that way. I was included in a conversation maybe 2 years ago with someone that did some UTF8 filename research through the package repositories, but there haven't been any issues raised. An example of the options would be the existing UTF8: "NetLock Arany (Class Gold) Főtanúsítvány" or: "NetLock Arany (Class Gold) F..tan..s..tv..ny" F..who? :) I think the native UTF8 is a better option. It's probably a bug if some file widget does not handle UTF8 files correctly. -- Kind regards, Michael
Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)
On 2/28/19 4:30 PM, James Pooton wrote: > >> What version of the openssl package is installed? > > Currently we’ve got the following versions getting installed: > > openssl: Installed: 1.1.1a-1 Candidate: 1.1.1a-1 Version table: *** > 1.1.1a-1 500 500 http://deb.debian.org/debian buster/main armhf > Packages 100 /var/lib/dpkg/status > > ca-certificates: Installed: 20190110 Candidate: 20190110 Version > table: *** 20190110 500 500 http://deb.debian.org/debian buster/main > armhf Packages 100 /var/lib/dpkg/status > > >> This does sound like a potential issue with `openssl rehash`. Your >> workaround looks OK for the moment, but the problem is that the >> openssl devs would like to remove the deprecated `c_rehash` >> utility. At this point in the release cycle, it's possible c_rehash >> may stick around for Buster, but no guarantees from me on that one >> - that's up to the openssl folks. > > Yep.. I actually read about that in the issue where that was > changed. Just wasn’t able to get ‘openssl rehash’ to work myself > either, so fell back to the deprecated call for now. > > >>> qemu: Unsupported syscall: 382 >> >> I can't find what syscall 382 should be, it seems to be higher than >> all the numbers I can find, the higest number is 294. > > I’m with you on that. It’s odd, but that’s the syscall number I’ve > seen on Docker for Mac, Windows, and Linux using QEMU. Linux also > kicks out some 384 but it didn’t appear related. > >> Can you give combination of ca-certificates / openssl that works / >> fails? > > I actually was looking to see if I could just apt install the > previous packages to verify things, but they don’t seem to be options > in the repo any more according to apt-cache. But I’ll see if I can’t > find the previous packages that were being install when things were > building fine. I’ll let you know. 20170717 was the previous version in testing (20180409 introduced the `openssl rehash` usage and was kept from testing for an important bug). 20170717 used the perl c_rehash utility. If you need it, here it is! http://snapshot.debian.org/package/ca-certificates/20170717/#ca-certificates_20170717 -- Kind regards, Michael
Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)
What version of the openssl package is installed? This does sound like a potential issue with `openssl rehash`. Your workaround looks OK for the moment, but the problem is that the openssl devs would like to remove the deprecated `c_rehash` utility. At this point in the release cycle, it's possible c_rehash may stick around for Buster, but no guarantees from me on that one - that's up to the openssl folks. -- Kind regards, Michael
Bug#922062: ca-certificates package post-installation script subprocess returned error exit status 1
On 2/11/19 12:51 PM, Michel Meyers wrote: > Mystery solved: Somebody (or something) placed a private key in a file > called privkey.pem and stored it in /etc/ssl/certs. This caused openssl > rehash to silently exit with error code 1, thus causing the whole > postinst script to fail. > > After cleaning out the offending file, the package installed without any > problems. Thanks for the debugging info. I tried to reproduce a non-zero exit from both the old c_rehash and new openssl rehash calls, in order to see if we've found another behavior difference, but each call ended up with a clean 0 exit for me with a key file in the same place. cd /etc/ssl/certs/ sudo cp ../private/ssl-cert-snakeoil.key privkey.pem sudo c_rehash -v . echo $? sudo openssl rehash -v . echo $? sudo update-ca-certificates --fresh -v echo $? sudo rm privkey.pem I do see an expected warning "rehash: warning: skipping privkey.pem,it does not contain exactly one certificate or CRL" but no non-zero exit. I do have the same version of openssl installed, 1.1.1a-1. I'd like to see if we can reproduce and maybe come up with some basic error avoidance, if this is a common practice to put keys here? (I wouldn't, so not sure how common this is.) Kind regards, Michael
Bug#922062: ca-certificates package post-installation script subprocess returned error exit status 1
Control: tag -1 moreinfo On 2/11/19 9:58 AM, Michel Meyers wrote: > > Setting up ca-certificates (20190110) ... > Updating certificates in /etc/ssl/certs... > dpkg: error processing package ca-certificates (--configure): > installed ca-certificates package post-installation script subprocess > returned error exit status 1 > -- > > It's not quite clear why (error message doesn't point to a particular > issue). I'm thinking it's something on this box causing the postinst > script to error out, but have no leads as to > what. Tagging moreinfo. I guess you could escalate `dpkg --debug=$X` troubleshooting on your system. Corrupt file? Bad disk? etc. If it's hardware and not related to ca-certificates, we should close this. Thanks, Michael
Bug#920348: ca-certificates.crt bundle gets temporarily removed during update-ca-certificates
On 1/24/19 7:54 AM, Dimitris Aragiorgis wrote: > > It seems that update-ca-certificates temporarily removes the > /etc/ssl/certs/ca-certificates.crt bundle. I remember this bug. c_rehash behavior was "fixed" at some point and resulted in multiple symlinks to ca-certificates.crt, so moving it out of the way first was the workaround. https://bugs.debian.org/643667 and the linked LP bug within have the details. > As a result, whoever uses this file explicitly, e.g. python-requests via > DEFAULT_CA_BUNDLE_PATH, might fail during a system-wide > update-ca-certificates. > > Removing this file is practically unesseccery since a few lines below, > the script replaces it atomically using mv. > > Note, that currently, if we skip the removal of the bundle we get the > following openssl rehash warning: > > rehash: warning: skipping ca-certificates.crt,it does not contain exactly > one certificate or CRL > > Still `openssl rehash` exits normally. The above warning will show up > only in debug mode (with --verbose). Nice. > Attached is a patch that fixes the above "racy" behavior. Thanks for the bug report and patch, this is a good cleanup from dropping c_rehash that I hadn't considered looking for. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#919433: RFS: ca-certificates/20190110 [RC;Security]
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "ca-certificates"
* Package name: ca-certificates
Version : 20190110
* License : GPL-2+, MPL-2.0
Section : misc
It builds those binary packages:
ca-certificates - Common CA certificates
ca-certificates-udeb - Common CA certificates - udeb (udeb)
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ca-certificates
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20190110.dsc
Changes since the last upload:
ca-certificates (20190110) unstable; urgency=high
* debian/control:
Depend on openssl (>= 1.1.1).
Set Standards-Version: 4.3.0.1.
Set Build-Depends: debhelper-compat (= 12); drop d/compat
Remove trailing whitespace from d/changelog.
* debian/ca-certificates.postinst:
Fix permissions on /usr/local/share/ca-certificates when using symlinks.
Closes: #916833
* sbin/update-ca-certificates:
Remove orphan symlinks found in /etc/ssl/certs to prevent `openssl
rehash` from exiting with an error. Closes: #895482, #895473
This will also fix removal of user CA certificates from /usr/local
without
needing to run --fresh. Closes: #911303
* mozilla/{certdata.txt,nssckbi.h}:
Update Mozilla certificate authority bundle to version 2.28.
The following certificate authorities were added (+):
+ "GlobalSign Root CA - R6"
+ "OISTE WISeKey Global Root GC CA"
The following certificate authorities were removed (-):
- "Certplus Root CA G1"
- "Certplus Root CA G2"
- "OpenTrust Root CA G1"
- "OpenTrust Root CA G2"
- "OpenTrust Root CA G3"
- "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
- "Visa eCommerce Root"
-- Michael Shuler Thu, 10 Jan 2019 19:31:31 -0600
--
Kind regards,
Michael
signature.asc
Description: OpenPGP digital signature
Bug#918957: RFS: ifmetric/0.3-5
Package: sponsorship-requests
Severity: normal
Hi mentors,
I am looking for a sponsor for "ifmetric", as well as possible support
for allowing me to upload as a DM.
Previous uploaders, since I've adopted ifmetric:
Gianfranco Costamagna
Nicholas Breen
This is not a frequently updated package and I'm not learning anything
new by just asking other people to upload every couple years. I have
requested support for DM upload on ifmetric from one of my
ca-certificates uploaders and received no reply (it was a long time ago..).
Anyway, here's the changelog, and if you're so inclined, I would be very
appreciative of a review of the changes and allowing me to do the actual
upload after a:
dcut dm --uid 0xA278B781FE4B2BDA --allow ifmetric
* Package name: ifmetric
Version : 0.3-5
Upstream Author : Lennart Poettering
* URL : http://0pointer.de/lennart/projects/ifmetric/
* License : GPL-2+
Section : net
It builds those binary packages:
ifmetric - Set routing metrics for a network interface
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ifmetric
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/i/ifmetric/ifmetric_0.3-5.dsc
Changes since the last upload:
ifmetric (0.3-5) unstable; urgency=medium
* debian/{compat,control,copyright}:
Update to debhelper-compat (= 12) build dependency; drop d/compat
Update to standards version 4.3.0.1
Update to salsa Vcs-Browser/Vcs-Git URLs
Update to priority optional
Update to https copyright format URL
* Fix "NETLINK: Error: Invalid argument" for links that are down in kernel
4.4+. Thanks for the patch, Jim Paris. Closes: #864889
-- Michael Shuler Thu, 10 Jan 2019 13:17:26 -0600
The package is lintian clean with a couple pedantic warnings.
The package shows 2 warnings on the mentors site that I have not been
able to resolve (bugs with mentors site?):
- Buildsystem: Package uses debhelper with an old compatibility level
- package is using: Build-Depends: debhelper-compat (= 12)
- Watch file is not present
- package has a d/watch file and uscan works as expected
I appreciate your time, and let me know if I need to fix something up.
Kind regards,
Michael
Bug#864889: ifmetric: "NETLINK: Error: Invalid argument" for links that are down, in kernel 4.4+
Control: tags -1 + pending Quick update for the new git repo location and tag pending. https://salsa.debian.org/mshuler-guest/ifmetric -- Kind regards, Michael
Bug#911303: Symlink not removed when certificates from /usr/local/share/ca-certificates is removed
On 10/18/18 8:08 AM, Laurent Bigonville wrote: > > In the past I've added certificates in /usr/local/share/ca-certificates > > After running update-ca-certificates symlinks were added in > /etc/ssl/certs > > After removing the files from /usr/local/share/ca-certificates and > running update-ca-certificates again, the symlinks are not removed and > are now broken. A patch for a couple other bug reports is going to fix this without running `update-ca-certificates --fresh`. Using --fresh will remove *all* symlinks and generate the entire set, so that will always work in this case. https://salsa.debian.org/debian/ca-certificates/commit/cfe7064cb707ed2e8ac587877c1153029d46dc28 This is going to find and remove any broken symlinks from /etc/ssl/certs before running `openssl rehash`, so we should catch a removal of a custom certificate from /usr/local/share/ca-certificates. -- Kind regards, Michael
Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4
I've been able to test this error by creating a bogus symlink in /etc/ssl/certs and I committed a patch that removes any orphan symlinks, prior to running `openssl rehash`. https://salsa.debian.org/debian/ca-certificates/commit/cfe7064cb707ed2e8ac587877c1153029d46dc28 -- Kind regards, Michael.
Bug#916833: SECURITY: world writable /srv/local/share/ca-certificates
On 12/19/18 3:10 AM, Maurizio Sartori wrote: > >* Possible correction > The problem seems to be in > /var/lib/dpkg/info/ca-certificates.postinst > the stat command should have the '-L' switch > > So for example: > chmod $(stat -c %a /usr/local) /usr/local/share/ca-certificates > chown $(stat -c %u /usr/local):$(stat -c %g /usr/local) > /usr/local/share/ca-certificates > should became > chmod $(stat -c %a -L /usr/local) /usr/local/share/ca-certificates > chown $(stat -c %u -L /usr/local):$(stat -c %g -L /usr/local) > /usr/local/share/ca-certificates Thanks for the bug report. -- Kind regards, Michael
Bug#911289: ca-certificates should remove Symantec certs
Thanks, I'll take a look. From memory, I recall this was a "certificates after X date" logic in NSS, but the CAs are still in certdata.txt. -- Kind regards, Michael
Bug#911303: Symlink not removed when certificates from /usr/local/share/ca-certificates is removed
Did you run `update-ca-certificates --fresh`? That's the flag that clears all symlinks, then updates. -- Kind regards, Michael On 10/18/18 8:08 AM, Laurent Bigonville wrote: > Package: ca-certificates > Version: 20180409 > Severity: normal > File: /usr/sbin/update-ca-certificates > > Hi, > > In the past I've added certificates in /usr/local/share/ca-certificates > > After running update-ca-certificates symlinks were added in > /etc/ssl/certs > > After removing the files from /usr/local/share/ca-certificates and > running update-ca-certificates again, the symlinks are not removed and > are now broken. > > I don't think this is intended, isn't it? > > Kind regards, > > Laurent Bigonville > > -- System Information: > Debian Release: buster/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy > > Versions of packages ca-certificates depends on: > ii debconf [debconf-2.0] 1.5.69 > ii openssl1.1.1-1 > > ca-certificates recommends no packages. > > ca-certificates suggests no packages. > > -- debconf information excluded >
Bug#908858: ca-certificates: hidden dependency on default-jre
Control: reassign -1 ca-certificates-java 20180516 Purge (not just remove) of the ca-certificates-java package should remove config files, including /etc/ca-certificates/update.d/jks-keystore. Reassigning to appropriate package, ca-certificates-java, but perhaps this is wontfix. -- Kind regards, Michael On 09/15/2018 01:58 AM, Marc Lehmann wrote: > Package: ca-certificates > Version: 20161130+nmu1+deb9u1 > Severity: normal > > Dear Maintainer, > > I get this error when installing openjdk-8-jre:i386 on an amd64 system, which > pulls in > ca-certificates-java automatically: > >Processing triggers for ca-certificates (20161130+nmu1+deb9u1) ... >Updating certificates in /etc/ssl/certs... >0 added, 0 removed; done. >Running hooks in /etc/ca-certificates/update.d... > >/etc/ca-certificates/update.d/jks-keystore: 86: > /etc/ca-certificates/update.d/jks-keystore: java: Permission denied >E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. > > The way this happened is that I uninstalled opendjk-8.*, which removed > ca-certificates-java and default-jre. The result was that there was no "java" > executable in the PATH anymore. > > Then, during installation of openjdk-8-jre:i386, I got the above error. > > I was able top work around this by installing default-jre again, which gave > me a java executable. > > I don't know if this is a problem in ca-certificates, ca-certificates-java, > openjdk or elsewhere, so apologies if I report this against the wrong package. > > -- System Information: > Debian Release: 9.5 > APT prefers stable > APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.18.7-041807-generic (SMP w/4 CPU cores) > Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C > (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages ca-certificates depends on: > ii debconf [debconf-2.0] 1.5.61 > ii openssl1.1.0f-3+deb9u2 > > ca-certificates recommends no packages. > > ca-certificates suggests no packages. > > -- debconf information excluded >
Bug#903204: ca-certificates: Errors on updating to 20141019+deb8u4
Control: tags -1 + moreinfo On 07/07/2018 10:21 AM, guidot wrote: > I just updated from 20141019+deb8u3 to 20141019+deb8u4 using > > aptitude safe-upgrade > > and got these errors: > > Updating certificates in /etc/ssl/certs... unable to load certificate > 140549699909264:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong > tag:tasn_dec.c:1219: > 140549699909264:error:0D07803A:asn1 encoding > routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:386:Type=X509 > WARNING: dhparam.pem does not contain a certificate or CRL: skipping > 20 added, 42 removed; done. > > I don't understand what went wrong here. I'm pretty sure I didn't touch > anything in /etc/ssl/certs, my local certs are stored elsewhere. This appears to be a warning from c_rehash on a non-certificate pem file `dhparam.pem` found in /etc/ssl/certs, then success on the 20 new and 42 removed CA certificates in this update. For clarity, did the installation of update packages complete successfully, or did it exit non-zero with an error from aptitude/dpkg? I'm pretty sure an `ls -l /etc/ssl/certs/dhparam.pem` would indeed return the file, which is not a part of the ca-certificates package. Searching around for dhparam.pem, it appears this is a Diffie-Hellman option file for using a larger key than the openssl default. I found quite a few web pages that say to put it there. The warning should be innocuous, but I'd suggest moving it to a better location. For instance, I found a number of nginx how-to pages that use the /etc/ssl/certs location, but I would think it should be appropriate to put the file at `/etc/nginx/ssl/dhparam.pem` and configure nginx to find it there. Setting bug to moreinfo. -- Kind regards, Michael
Bug#901288: stretch-pu: package ca-certificates/20161130+nmu1
On 07/05/2018 03:37 PM, Adam D. Barratt wrote: On Sun, 2018-06-10 at 21:22 -0500, Michael Shuler wrote: I would like to upload ca-certificates_20161130+nmu1+deb9u1 with the following fixes: - update Mozilla CA bundle in Stretch to 2.22 (#858064) - fix postinst failure on read-only /usr/local (#843722) - remove Christian Perrier from uploaders per his request (#894070) The Uploaders change is basically a no-op in stable, but please go ahead, bearing in mind that the window for 9.5 closes this weekend. Thanks for the update. I emailed my the active Uploaders to see if they can push this up in the short timeframe. For clarification, were you asking that the Uploaders change be omitted, or was this just an FYI? Much appreciated. -- Kind regards, Michael
Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4
On 06/20/2018 04:33 PM, Sebastian Andrzej Siewior wrote: On 2018-06-13 08:19:32 [+0200], To Axel Beckert wrote: I asked upstream what they thing about ignoring these errors because the perl script does so. On the other hand what about cleaning up these dangling symlinks? ca-certificate maintainers: what do we do here? [ ] we intend to figure out why there are dangling symlinks, no need to change "openssl rehash" in anyway. [ ] we intend to figure out why there are dangling symlinks but in the meantime "openssl rehash" should not error out on them. [ ] "openssl rehash" should not error out on certificates which can not be opened. This is the old behavioud and required due to $reason. [x] I intend to find the time between work, family, and multiple other projects to attempt to reliably reproduce the problem, in order to intelligently answer the above. -- Kind regards, Michael
Bug#901352: unblock: ca-certificates/20180409
On 06/13/2018 02:35 AM, Cyril Brulebois wrote: It seems the block-udeb isn't the only blocker though: Migration status: BLOCKED: Rejected/introduces a regression Updating ca-certificates introduces new bugs: #895482 and I see no severity downgrade in that bug report? It was upgraded back to serious again, yesterday, after some testing feedback. Also, I should have mentioned this in my dda@ mail I suppose: 63 days old (needed 5 days) If a given package has spent that much time out of testing, it probably can wait a few days while we're going through the late stages of the d-i release process. It should only be a matter of days or hours now. ;) I'll get back to your package later if we spot any issues that would need to be addressed before we release; or it's going to be unblocked automatically when I unfreeze udebs. Thanks for the note, I appreciate it. -- Michael
Bug#901352: unblock: ca-certificates/20180409
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock ca-certificates-udeb is blocked. Please unblock the package ca-certificates to transition to testing. We just downgraded the severity of a bug, since openssl was updated to fix an issue with the processing of CA certificates[0], in order to allow ca-certificates to transition to testing. The bug is intended to be closed after testing transition, just to be sure all is well, since the fix was really in openssl. It appears that ca-certificates is now blocked due to udebs being frozen[1], as noted a couple days ago on d-d-announce (thank you for this note!). Kind regards, Michael Shuler [0] https://bugs.debian.org/895482 [1] https://qa.debian.org/excuses.php?package=ca-certificates
Bug#889852: ca-certificates: piuparts failure causes piuparts failures in (all?) dependent packages
Control: tags -1 + moreinfo On 02/07/2018 03:29 PM, Nicholas D Steeves wrote: https://piuparts.debian.org/stretch2buster-rcmd/fail/ca-certificates_20170717.log 1m9.6s DEBUG: Modified(user, group, mode, size, target): /etc/ca-certificates.conf expected(root, root, - 100644, 6488, None) != found(root, root, - 100644, 7694, None) 1m9.7s INFO: Warning: Package purging left files on system: /etc/ca-certificates.conf.dpkg-oldnot owned 1m9.7s ERROR: FAIL: After purging files have been modified: /etc/ca-certificates.conf not owned I'm not really sure what piuparts is testing here, nor how to suppress this error. debian/ca-certificates.postrm in purge does: rm -f /etc/ca-certificates.conf* This configuration file is nearly guaranteed to be modified, so it should be expected to have a different size. On a fresh VM, installing and purging the package, the config files are removed as I would expect. If there is some reasonable way for piuparts to ignore a configuration file that is expected to be modified, I'd like to know how to add this exclusion to ca-certificate to prevent this error, particularly if it's affecting other packages. -- Kind regards, Michael
Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
On 06/08/2018 03:37 PM, Adam D. Barratt wrote: Ping? We're a week away from the final chance to get an update into jessie-as-oldstable before it becomes jessie-lts. Thanks for the ping. I updated the debian-jessie branch of ca-certificates with mozilla bundle 2.22, and it's ready to be uploaded. Thijs, might you have a chance to upload 20141019+deb8u4 to jessie-updates? If not, perhaps we can wrangle someone else to help. commit: ce1498e496b749f71fd96d60942d2c2aa7fdf0ca $ git diff --stat debian/20141019+deb8u3 debian-jessie debian/changelog |74 + debian/control | 1 - mozilla/certdata.txt | 28220 +-- mozilla/nssckbi.h|39 +- 4 files changed, 10787 insertions(+), 17547 deletions(-) Thanks all! -- Kind regards, Michael
Bug#895482: severity 895482 important
severity 895482 important thanks Dropped severity to allow testing migration. -- Michael
Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4
On 05/30/2018 12:46 PM, Sebastian Andrzej Siewior wrote: I've read about this bug (and the other one) on d-devel. I uploaded recently a new version of openssl to unstable (1.1.0h-3)which changes the exit code of "openssl rehash" to zero in case of a duplicate or if a certificate can no be open. I left this bug open in case the maintainer of this package wants to investigate why there are duplicates or non-existing certificates. Thanks for the update, Sebastian. OpenSSL commit for my own reference and for others, if interested: https://github.com/openssl/openssl/commit/e6a833cb97ed762408b57ea3efa83bd10c1d2a78 -- Kind regards, Michael
Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4
Thanks for the details. #895473 reported a similar error on locally installed CA certificates, which I think may be related. Each of the list of `rehash: skipping .. cannot open file` in your errors appears to be on CAs that were removed in the package during this update, so somewhere we have a problem with `openssl rehash` trying to link to files we removed, but for some reason were not prefixed with '!' in /etc/ca-certificates.conf. I've tried a number of upgrades from a March 29 unstable chroot, as well as from stretch to unstable on openstack instances, on both amd64 and i386 (I don't think arch is dependent), and I've been unable to get a similar error to present itself. Each way I've tried, I get the package-removed certificates prefixed properly and no errors, so haven't been able to reproduce this, yet. I will keep trying with different options and see if I can figure out where the problem is. If someone has a good way to reproduce, I'd appreciate it! -- Kind regards, Michael
Bug#895473: ca-certificates: Post-install script subprocess return error exit status 3 while upgrading
On 04/11/2018 04:01 PM, Pr0metheus wrote: > >* What led up to the situation? > > apt-get upgrade > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Cannot fix the problem > >* What was the outcome of this action? > > Setting up ca-certificates (20180409) ... > Updating certificates in /etc/ssl/certs... > rehash: skipping duplicate certificate in HaricaRootCA2011.pem > rehash: skipping vpn.auth.gr.pem, cannot open file > rehash: skipping AutCentralCAR5.pem, cannot open file > dpkg: error processing package ca-certificates (--configure): > installed ca-certificates package post-installation script subprocess > returned > error exit status 3 > Errors were encountered while processing: > ca-certificates > E: Sub-process /usr/bin/dpkg returned an error code (1) > >* What outcome did you expect instead? > > Like previous upgrades, maintain my existing list and update the rest. Thanks for the bug report. I'm having trouble reproducing a similar error reported in #895482 on package-removed CAs and have not merged these reports because this error appears to be on locally installed certificates. I believe they are related, however. I will keep trying to reproduce and identify where the problem might be. -- Kind regards, Michael
Bug#894295: ca-certificates fails to install: Execution of /usr/bin/c_rehash aborted due to compilation errors
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894282 This appears to be a bug in openssl with a new version to address the regression. -- Kind regards, Michael On 03/28/2018 09:07 AM, Helmut Grohne wrote: > Package: ca-certificates > Version: 20170717 > Severity: grave > Justification: fails to install > User: helm...@debian.org > Usertags: rebootstrap > > In a fresh sid amd64 chroot: > > # apt-get install ca-certificates > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following additional packages will be installed: > libssl1.1 openssl > The following NEW packages will be installed: > ca-certificates libssl1.1 openssl > 0 upgraded, 3 newly installed, 0 to remove and 22 not upgraded. > Need to get 2274 kB of archives. > After this operation, 5394 kB of additional disk space will be used. > Do you want to continue? [Y/n] > Get:1 http://ftp.stw-bonn.de/debian sid/main amd64 libssl1.1 amd64 1.1.0h-1 > [1352 kB] > Get:2 http://ftp.stw-bonn.de/debian sid/main amd64 openssl amd64 1.1.0h-1 > [744 kB] > Get:3 http://ftp.stw-bonn.de/debian sid/main amd64 ca-certificates all > 20170717 [178 kB] > Fetched 2274 kB in 2s (1181 kB/s) > debconf: delaying package configuration, since apt-utils is not installed > Selecting previously unselected package libssl1.1:amd64. > (Reading database ... 10089 files and directories currently installed.) > Preparing to unpack .../libssl1.1_1.1.0h-1_amd64.deb ... > Unpacking libssl1.1:amd64 (1.1.0h-1) ... > Selecting previously unselected package openssl. > Preparing to unpack .../openssl_1.1.0h-1_amd64.deb ... > Unpacking openssl (1.1.0h-1) ... > Selecting previously unselected package ca-certificates. > Preparing to unpack .../ca-certificates_20170717_all.deb ... > Unpacking ca-certificates (20170717) ... > Processing triggers for libc-bin (2.27-2) ... > Setting up libssl1.1:amd64 (1.1.0h-1) ... > Setting up openssl (1.1.0h-1) ... > Setting up ca-certificates (20170717) ... > Updating certificates in /etc/ssl/certs... > Unknown regexp modifier "/b" at /usr/bin/c_rehash line 15, at end of line > Unknown regexp modifier "/W" at /usr/bin/c_rehash line 26, at end of line > Unknown regexp modifier "/3" at /usr/bin/c_rehash line 26, at end of line > Unknown regexp modifier "/2" at /usr/bin/c_rehash line 26, at end of line > No such class installdir at /usr/bin/c_rehash line 58, near "Prefix our > installdir" > (Might be a runaway multi-line // string starting on line 26) > syntax error at /usr/bin/c_rehash line 58, near "Prefix our installdir" > Can't redeclare "my" in "my" at /usr/bin/c_rehash line 63, near "my" > Execution of /usr/bin/c_rehash aborted due to compilation errors. > dpkg: error processing package ca-certificates (--configure): > installed ca-certificates package post-installation script subprocess > returned error exit status 255 > Processing triggers for libc-bin (2.27-2) ... > Errors were encountered while processing: > ca-certificates > E: Sub-process /usr/bin/dpkg returned an error code (1) > # > > Helmut >
Bug#874120: ca-certificates: should "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" be trusted by default?
On 09/03/2017 09:09 AM, Julien Cristau wrote: > ca-certificates 20170717 added the "TUBITAK Kamu SM SSL Kok Sertifikasi > - Surum 1" CA, but when that was added to nss it was restricted to a > small set of domains[1]. Thus I wonder if it wouldn't be better to > blacklist it from ca-certificates, since we can't encode this kind of > constraint. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1349705 There are a number of technically constrained CAs. I'm not sure blacklisting would be the right answer for Debian/derivative users, since that makes the CA certificate completely uninstalled by the package and never able to be used. In the best case scenario, the CA abides by the technical constraints and never issues a certificate outside of their allowed domains, and there are no problems. I understand this isn't an ideal world, security issues happen, but I also don't wish to punish users of a technically constrained CA, since there's no mechanism in ca-certificates for this check, like there is in NSS. I don't have a great idea at the moment, but do think blacklisting a technically constrained CA is a bit heavy handed. -- Michael signature.asc Description: OpenPGP digital signature
Bug#864889: ifmetric: "NETLINK: Error: Invalid argument" for links that are down, in kernel 4.4+
On 07/21/2017 12:46 AM, Michael Shuler wrote: > I committed this patch to git and started to test, but it fails to > compile for me. Quick repro: > > git clone https://anonscm.debian.org/git/collab-maint/ifmetric.git > cd ifmetric/ > git-buildpackage > > Due to hardening flags that are used for Debian packages, this needs > some definition before use. Building on a Strech machine appears to work, so ignore my error for now :) -- Kind regards, Michael
Bug#767272: Bug#866670: ca-certificates: update-ca-certificates -f does not pass removed certs to hooks
Testing against a new build for jessie, it looks as if the ca-certificates-java hook does nothing with new CA certificate additions, either? None of the newly added CAs appear to have made it to the keystore upon package upgrade, but were added in --fresh. It appears the hook is not doing the right thing in either add/remove case. Just wanted to let you know I've taken a quick look, but I'm not sure what the real issue is, at this moment. (test stdout attached) -- Kind regards, Michael mshuler@hana:~$ sudo apt-get install ca-certificates=20141019+deb8u4 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: ca-certificates 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 196 kB of archives. After this operation, 70.7 kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! ca-certificates Install these packages without verification? [y/N] y Get:1 http://www.pbandjelly.org/debian/ ./ ca-certificates 20141019+deb8u4 [196 kB] Fetched 196 kB in 0s (1,513 kB/s) Reading changelogs... Done Preconfiguring packages ... (Reading database ... 278491 files and directories currently installed.) Preparing to unpack .../ca-certificates_20141019+deb8u4_all.deb ... Unpacking ca-certificates (20141019+deb8u4) over (20141019+deb8u3) ... Processing triggers for man-db (2.7.0.2-5) ... Setting up ca-certificates (20141019+deb8u4) ... Updating certificates in /etc/ssl/certs... 12 added, 24 removed; done. Processing triggers for ca-certificates (20141019+deb8u4) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d done. done. mshuler@hana:~$ mshuler@hana:~$ mshuler@hana:~$ sudo update-ca-certificates --fresh --verbose Clearing symlinks in /etc/ssl/certs...done. Updating certificates in /etc/ssl/certs... Doing . SwissSign_Silver_CA_-_G2.pem => 57bcb2da.0 SwissSign_Silver_CA_-_G2.pem => 5046c355.0 Entrust_Root_Certification_Authority.pem => 6b99d060.0 Entrust_Root_Certification_Authority.pem => bf64f35b.0 AC_RAIZ_FNMT-RCM.pem => cd8c0d63.0 AC_RAIZ_FNMT-RCM.pem => b936d1c6.0 Entrust_Root_Certification_Authority_-_G2.pem => 02265526.0 Entrust_Root_Certification_Authority_-_G2.pem => 455f1b52.0 T-TeleSec_GlobalRoot_Class_2.pem => 1e09d511.0 T-TeleSec_GlobalRoot_Class_2.pem => d06393bb.0 SZAFIR_ROOT_CA2.pem => fe8a2cd8.0 SZAFIR_ROOT_CA2.pem => a81e292b.0 Trustis_FPS_Root_CA.pem => d853d49e.0 Trustis_FPS_Root_CA.pem => c51c224c.0 DigiCert_Trusted_Root_G4.pem => 75d1b2ed.0 DigiCert_Trusted_Root_G4.pem => a2c66da8.0 IdenTrust_Commercial_Root_CA_1.pem => ef954a4e.0 IdenTrust_Commercial_Root_CA_1.pem => d18e9066.0 ssl-cert-snakeoil.pem => 2781bb9b.0 ssl-cert-snakeoil.pem => 548bcbf5.0 TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.pem => ff34af3f.0 TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.pem => 31188b5e.0 SwissSign_Gold_CA_-_G2.pem => 4f316efb.0 SwissSign_Gold_CA_-_G2.pem => 3c860d51.0 DigiCert_Global_Root_G2.pem => 607986c7.0 DigiCert_Global_Root_G2.pem => c90bc37d.0 CFCA_EV_ROOT.pem => 0b1b94ef.0 CFCA_EV_ROOT.pem => 9282e51c.0 Global_Chambersign_Root_-_2008.pem => 0c4c9b6c.0 Global_Chambersign_Root_-_2008.pem => 9f533518.0 Network_Solutions_Certificate_Authority.pem => 4304c5e5.0 Network_Solutions_Certificate_Authority.pem => 2fa87019.0 Swisscom_Root_CA_1.pem => 667c66d4.0 Swisscom_Root_CA_1.pem => e60bf0c0.0 GlobalSign_Root_CA.pem => 5ad8a5d6.0 GlobalSign_Root_CA.pem => b0f3e76e.0 AddTrust_Qualified_Certificates_Root.pem => e536d871.0 AddTrust_Qualified_Certificates_Root.pem => 052e396b.0 GlobalSign_ECC_Root_CA_-_R5.pem => 1d3472b9.0 GlobalSign_ECC_Root_CA_-_R5.pem => 2add47b6.0 GeoTrust_Primary_Certification_Authority_-_G3.pem => e2799e36.0 GeoTrust_Primary_Certification_Authority_-_G3.pem => c7e2a638.0 DigiCert_Global_Root_G3.pem => dd8e9d41.0 DigiCert_Global_Root_G3.pem => ed39abd0.0 Symantec_Class_2_Public_Primary_Certification_Authority_-_G6.pem => 1320b215.0 Symantec_Class_2_Public_Primary_Certification_Authority_-_G6.pem => 0708417d.0 Entrust_Root_Certification_Authority_-_EC1.pem => 106f3e4d.0 Entrust_Root_Certification_Authority_-_EC1.pem => b3fb433b.0 AffirmTrust_Premium.pem => b727005e.0 AffirmTrust_Premium.pem => dbc54cab.0 Symantec_Class_1_Public_Primary_Certification_Authority_-_G6.pem => 26312675.0 Symantec_Class_1_Public_Primary_Certification_Authority_-_G6.pem => b6782d18.0 QuoVadis_Root_CA_1_G3.pem => 749e9e03.0 QuoVadis_Root_CA_1_G3.pem => 52b525c7.0 S-TRUST_Universal_Root_CA.pem => 19c1fa33.0 S-TRUST_Universal_Root_CA.pem => 631c779f.0 GeoTrust_Primary_Certification_Authority_-_G2.pem => 116bf586.0 GeoTrust_Primary_Certification_Authority_-_G2.pem => 27af790d.0 TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem => 65b876bd.0 TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem => 418595b9.0 SecureSign_RootCA11.pem => 18856ac4.0 SecureSign_RootCA11.pem
Bug#721976: ca-certificates contains both server and email certificates
The patch was committed to collab-maint master a few days ago and I tagged this bug as pending yesterday. It's on the way :) -- Kind regards, Michael
Bug#864889: ifmetric: "NETLINK: Error: Invalid argument" for links that are down, in kernel 4.4+
I committed this patch to git and started to test, but it fails to
compile for me. Quick repro:
git clone https://anonscm.debian.org/git/collab-maint/ifmetric.git
cd ifmetric/
git-buildpackage
Due to hardening flags that are used for Debian packages, this needs
some definition before use.
--
Kind regards,
Michael
(master)mshuler@hana:~/git/ifmetric$ git-buildpackage
dpkg-buildpackage -rfakeroot -D -us -uc -i -I
dpkg-buildpackage: source package ifmetric
dpkg-buildpackage: source version 0.3-5
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Michael Shuler <mich...@pbandjelly.org>
dpkg-source -i -I --before-build ifmetric
dpkg-buildpackage: host architecture amd64
dpkg-source: info: using options from ifmetric/debian/source/local-options:
--unapply-patches --abort-on-upstream-changes
dpkg-source: info: applying ifmetric.c_typo
dpkg-source: info: applying nlrequest.c_packet-too-small_fix
dpkg-source: info: applying ifmetric.8_typo
dpkg-source: info: applying ifmetric.c_netlink-invalid-arg
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
dh_autoreconf_clean
dh_clean
dpkg-source -i -I -b ifmetric
dpkg-source: info: using options from ifmetric/debian/source/local-options:
--unapply-patches --abort-on-upstream-changes
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building ifmetric using existing ./ifmetric_0.3.orig.tar.gz
dpkg-source: info: building ifmetric in ifmetric_0.3-5.debian.tar.xz
dpkg-source: info: building ifmetric in ifmetric_0.3-5.dsc
debian/rules build
dh build
dh_testdir
dh_update_autotools_config
dh_autoreconf
configure.ac:36: installing './compile'
dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for memset... yes
checking for socket... yes
checking for strerror... yes
checking for strrchr... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for unistd.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking for ANSI C header files... (cached) yes
checking whether ln -s works... yes
checking for pid_t... yes
checking linux/version.h usability... yes
checking linux/version.h presence... yes
checking for linux/version.h... yes
checking for lynx... yes
checking for xmltoman... no
configure: WARNING: *** Not rebuilding man pages as xmltoman is not found ***
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating src/Makefile
config.status: creating Makefile
config.status: creating man/Makefile
config.status: creating doc/Makefile
config.status: creating doc/README.html
config.status: creating config.h
config.status: executing depfiles commands
configure: WARNING: unrecognized options: --disable-maintainer-mode
dh_auto_build
make -j1
make[1]: Entering directory '/home/mshuler/git/ifmetric'
make all-recursive
make[2]: Entering directory '/home/mshuler/git/ifmetric'
Making all in src
make[3]: Entering directory '/home/mshuler/git/ifmetric/sr
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
On 07/06/2017 11:13 PM, Paul Wise wrote: > On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote: > >> For what it's worth, my opinion is that we should attempt to synchronize >> certdata.txt (and blacklist.txt, for that matter) across all suites (but >> not other changes to the packaging). This would remove another decision >> point in our infrastructure and ensure harmonious X509 processing across >> suites. > > I would like to see that happen too. I spent a few sessions over the past few days getting the mozilla bundle 2.14 committed to all the suite branches wheezy and newer. I have some more verification to work on and I'll get some packages rolled up and tested for all the suites. I appreciate the notes here! -- Kind regards, Michael
Bug#864889: ifmetric: "NETLINK: Error: Invalid argument" for links that are down, in kernel 4.4+
Hi Jim, Thanks for the patch. Do you happen to know if this patch presents any adverse behavior on kernel versions <4.4, or if this ends up being a no-op? I ask because Jessie is 3.16 by default, with a 4.9 kernel version in backports. Thanks! Michael
Bug#721976: ca-certificates contains both server and email certificates
On 05/26/2017 02:18 PM, Jacob Hoffman-Andrews wrote: > Hi, just checking in on the status of this. I provided a patch above; > does it look good to you? The patch is simple, so I see no particular issue with it. My time has been crunched lately, but I have some vacation soon with plans for some Debian work. I will get this committed for the next release round for unstable and mark it pending when I do so. Thanks for the ping and your patience. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates
On 05/19/2017 10:07 AM, Chris Lamb wrote: > I've uploaded ca-certificates 20161130+nmu1 to DELAYED/5: > > ca-certificates (20161130+nmu1) unstable; urgency=medium > > * Non-maintainer upload. > * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they > are > now untrusted by the major browser vendors. Closes: #858539 Thank you for the NMU, Chris, I'm good with that change. -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#852040: jessie-pu: package ca-certificates/20141019+deb8u3
On 04/28/2017 11:39 AM, Adam D. Barratt wrote: > On Fri, 2017-04-28 at 00:58 +0200, Andreas Beckmann wrote: >> >> Attached is the combined debdiff of the commits backported by Michael >> and me. I verified in piuparts that "running update-certificates without >> hooks initially" now actually works as intended. > > That looks okay, thanks. > > Please feel free to upload, bearing in mind that the window for 8.8 > closes over the weekend. Thank you so much. I'm sorry I've been ridiculously busy, and "I'll get to it this weekend" repeatedly hasn't materialized for me. -- Kind regards, Michael
Bug#843722: I've tested the fix
On 04/17/2017 03:22 PM, Thomas Lange wrote: > The fix works for me. Please try to fix it soon, so the fixed version > will be going into the stretch release. Thanks for the patch, Antoine, and confirmation, Thomas - I'll get an upload ready as soon as I can. -- Kind regards, Michael
Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates
On 03/23/2017 04:02 AM, Chris Lamb wrote: > StartCom and WoSign certificates are now untrusted by the major browser > vendors[0][1], making websites that use certs from these vendors > inaccessible. I followed these events on dev-security-policy and libnss performs date checks on certs signed by these roots, which ca-certificates has no facility to perform. > However, as this is not reflected in ca-certificates, tools such as curl > still intepret these as valid/secure. Blacklisting StartCom and WoSign roots will possibly invalidate some user's pre- Oct 21, 2016 valid certificates, but I think that is probably OK. > (This has a knock-on effect that health-check tools that use the output > of such tools to determine whether a site is "up" — eg. updown.io — will > misleadingly imply that the site is available to users when, in all > practical senses, they are not.) > > I would suggest we remove the offending authorities from ca-certificates > as soon as possible. > > > [0] > https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ > [1] My installation "chrome-stable" rejects them as well. Thanks for the report, Chris. -- Kind regards, Michael
Bug#721976: ca-certificates contains both server and email certificates
I appreciate the research and suggestions. I'd be happy to review a patch submission to fix this. I'm not a mutt nor S/MIME user, so perhaps there may be some fallout from simple removal of email-only roots, if there are people using them. There's no way I know of to tell how many users use specific CAs, other than bug reports of "you moved my cheese!", but we could ask for testers :-) -- Kind regards, Michael
Bug#858064: ca-certificates: Remove 1024-bit root certificates
On 03/20/2017 12:59 PM, Alex Gaynor wrote: > Confirmed that with the package from `git`, this is resolved! Awesome. Great! Thanks a bunch for the confirmation. -- Warm regards, Michael
Bug#858064: ca-certificates: Remove 1024-bit root certificates
Clone the repo and `dpkg-buildpackage`. -- Kind regards, Michael
Bug#858064: ca-certificates: Remove 1024-bit root certificates
Control: tags -1 - moreinfo + pending Thanks for the details. Those appear to be a few of the removals in the 2.11 bundle, which are committed, but not released yet. Those will make it to a stable proposed update, too. https://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/tree/debian/changelog -- Kind regards, Michael
Bug#858064: ca-certificates: Remove 1024-bit root certificates
Control: tags -1 + moreinfo On 03/17/2017 04:38 PM, Alex Gaynor wrote: > Package: ca-certificates > Severity: normal What version of ca-certificates? > The ca-certificates package includes legacy root certificates which have > 1024-bit RSA keys. These are considered weak by modern standards, and > have been removed from the upstream Mozilla trust store. Please, be specific: what 1024-bit roots? > For a while these were needed to workaround a bug in OpenSSL X.509 path > building logic, but that bug has since been resolved so these are now > vestigial and a risk. ca-certificates version 20140927 removed the 1024-bit certificates when updating the mozilla CA bundle to 2.1. Please, provide some details about your installation, otherwise, this was fixed long ago. -- Kind regards, Michael
Bug#825730: jessie-pu: package ca-certificates/20141019+deb8u3
Thanks for the follow up. I'll get this fixed and resubmit a new debdiff for stable update. -- Kind regards, Michael
Bug#783615: "update-ca-certificates --fresh" doesn't correctly re-add certificates in /usr/local/share/ca-certificates
PU request sent! https://bugs.debian.org/852040 Thanks again, Michael
Bug#852040: jessie-pu: package ca-certificates/20141019+deb8u3
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu I would like to upload ca-certificates_20141019+deb8u3 to stable, in order to backport the fix from #783615 [0]. This bug was reopened and set to Serious severity. The debdiff is attached. [0] https://bugs.debian.org/783615 -- Kind regards, Michael diffstat for ca-certificates-20141019+deb8u2 ca-certificates-20141019+deb8u3 debian/changelog|7 +++ sbin/update-ca-certificates |2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff -Nru ca-certificates-20141019+deb8u2/debian/changelog ca-certificates-20141019+deb8u3/debian/changelog --- ca-certificates-20141019+deb8u2/debian/changelog2016-11-18 09:24:20.0 -0600 +++ ca-certificates-20141019+deb8u3/debian/changelog2017-01-20 16:00:09.0 -0600 @@ -1,3 +1,10 @@ +ca-certificates (20141019+deb8u3) stable; urgency=medium + + * sbin/update-ca-certificates: +Update local certificates directory when calling --fresh. Closes: #783615 + + -- Michael Shuler <mich...@pbandjelly.org> Wed, 18 Jan 2017 15:54:56 -0600 + ca-certificates (20141019+deb8u2) stable; urgency=medium [ Michael Shuler ] diff -Nru ca-certificates-20141019+deb8u2/sbin/update-ca-certificates ca-certificates-20141019+deb8u3/sbin/update-ca-certificates --- ca-certificates-20141019+deb8u2/sbin/update-ca-certificates 2016-11-18 09:24:15.0 -0600 +++ ca-certificates-20141019+deb8u3/sbin/update-ca-certificates 2017-01-20 16:00:09.0 -0600 @@ -89,7 +89,7 @@ find . -type l -print | while read symlink do case $(readlink $symlink) in - $CERTSDIR*) rm -f $symlink;; + $CERTSDIR*|$LOCALCERTSDIR*) rm -f $symlink;; esac done find . -type l -print | while read symlink
Bug#783615: "update-ca-certificates --fresh" doesn't correctly re-add certificates in /usr/local/share/ca-certificates
On 01/18/2017 03:25 PM, Adrian Bunk wrote: > after a discussion with someone who ran into this bug in stable I have > set the severity to serious, since this should IMHO also be fixed in > stable. This does look like a good patch to backport to stable. I'll get this commited to git and work on a stable update. Thanks, Adrian! -- Kind regards, Michael
Bug#843722: (no subject)
On 01/01/2017 12:40 PM, Thomas Lange wrote: > There's still no fix. Do you need help for a fix? If you have a patch idea, that would be great! Apologies for the delay in getting something together to reproduce and test a fix. -- Kind regards, Michael
Bug#845456: Please add a udeb to ca-certificates
Just a quick follow up. Thijs uploaded ca-certificates_20161130 this morning, and it is currently in the NEW binary-BYHAND queue for approval. -- Kind regards, Michael
Bug#845456: Please add a udeb to ca-certificates
Thanks for the patches to enable the use of HTTPS in the installer. This does sound useful. (And apologies for the holiday delay in replying.) I'd like to complete a pending stable upload, first, then I'll work on this request. -- Kind regards, Michael
Bug#825730: ca-certificates: using --noawait triggers breaks downloader packages
Stable update requested! Thanks again for the report, Andreas. https://bugs.debian.org/844746 "jessie-pu: package ca-certificates/20141019+deb8u2" -- Kind regards, Michael Shuler signature.asc Description: OpenPGP digital signature
Bug#843722: wants to write to /usr/local
On 11/08/2016 10:07 PM, Thomas Lange wrote: > My /usr/local file system is mounted read-only via NFS. This results > in an error: > > > stretch[~]# dpkg --configure ca-certificates > Setting up ca-certificates (20161102) ... > chmod: changing permissions of '/usr/local/share/ca-certificates': Read-only > file system > dpkg: error processing package ca-certificates (--configure): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > ca-certificates Thanks for the report. I'd bet we can come up with a conditional to check this gracefully, so post-inst does not outright fail in this scenario. -- Kind regards, Michael
Bug#843121: RFS: ifmetric/0.3-4
Package: sponsorship-requests Severity: normal Dear mentors, I would appreciate a sponsor for this maintenance upload of ifmetric. This release updates the packaging standards to be current for Stretch. * Package name: ifmetric Version : 0.3-4 Upstream Author : Lennart Poettering <mzvszrg...@0pointer.de> * URL : http://0pointer.de/lennart/projects/ifmetric/ * License : GPL-2+ Section : net It builds those binary packages: ifmetric - Set routing metrics for a network interface To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ifmetric Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ifmetric/ifmetric_0.3-4.dsc Changes since the last upload: ifmetric (0.3-4) unstable; urgency=low * debian/control: Set Architecture: linux-any to exclude kfreebsd/hurd builds. Update to Standards-Version: 3.9.8. Update Vcs-Browser/Vcs-Git: https URLs. * debian/copyright: Drop recurrent license text for lintian. * debian/rules: Add hardening build flag for all options. * debian/patches/ifmetric.8_typo: Fix typo in man page. -- Michael Shuler <mich...@pbandjelly.org> Thu, 03 Nov 2016 18:09:20 -0500 Thanks for your time! -- Kind regards, Michael signature.asc Description: OpenPGP digital signature
Bug#825730: ca-certificates: using --noawait triggers breaks downloader packages
On 09/11/2016 03:48 AM, Andreas Beckmann wrote: > The fix is quite easy: we just need to run update-ca-certificates > *without* processing the hooks during postinst configure: > > update-ca-certificates --hooksdir "" Thanks Andreas! I'll test this out as soon as I can. > This should be backported to stable, too. I have a pending stable upload after the next unstable, so as long as test install works and this fits for stable-updates policy, I don't see a problem with that. -- Kind regards, Michael
Bug#828845: ca-certificates: update to Mozilla bundle 2.7
Control: tags -1 + pending On 08/04/2016 07:02 AM, Jonathan Wiltshire wrote: > Can I be any help in moving this along? It would be nice to get a stable > update underway too, and the next point release isn't far away. Thanks for the ping. I have committed the 2.7 bundle to the collab-maint master branch for unstable, along with a couple small standards updates. I've also committed the 2.7 bundle to the debian-jessie branch for a stable update. I'll make sure upgrades work properly tomorrow and let my sponsors know an upload is ready. > I'd be happy to get into co-maintaining if that would be helpful. The other uploaders are usually quick to help, but I appreciate the offer and will add you to uploaders and let you know if additional help is needed. -- Kind regards, Michael
Bug#825730: ca-certificates: using --noawait triggers breaks downloader packages
The ca-certificates triggers were added to deal with installation/upgrade problems in https://bugs.debian.org/537051 Do you have a suggested patch that also properly handles the issues presented in #537051? I would suggest that downloader packages possibly might pre-depend on ca-certificates, if that is required by the download, as a possible fix. I'm not sure if the trigger runs to completion first, as a pre-depend package. -- Kind regards, Michael
Bug#828845: ca-certificates: update to Mozilla bundle 2.7
On 06/28/2016 07:57 AM, Jonathan Wiltshire wrote: > > The attached patch updates the package to the latest Mozilla bundle. Thanks for the update patch and the recent bug triage, Jonathan. I appreciate the help! -- Warm regards, Michael signature.asc Description: OpenPGP digital signature
Bug#807274: wheezy-pu: package ca-certificates/20130119+deb7u2
Backlog of $REAL_LIFE work has kept me super busy. I ran into upgrade issues (sorry, don't have the existing bts#), and it looks like Ubuntu did a similar addition using a 'mozilla-1024/' directory, which may solve the immediate upgrade problem with previously removed certificates. I have not tested this out, yet, but will try to do so soon. -- Kind regards, Michael
Bug#816541: ca-certificates: avoid creating an empty /etc/java-6-sun
reassign 816541 ca-certificates-java 20140324 thanks See /etc/ca-certificates/update.d/jks-keystore hook, which is run by update-ca-certificates, but is from the ca-certificates-java. There are still users of Sun Java 6, so IMO, this is a non-issue, but I'll let the package maintainer decide whether this is a wontfix bug. -- Kind regards, Michael
Bug#812488: update of openssl still in limbo
On 02/22/2016 04:12 AM, Christian Beer wrote: > It seems that the openssl update is not happening soon. Can you please > include the 1024bit certificates again to solve this regression? Yeah, I have a work in progress branch that re-includes the 1024-bit CAs. Ran back into #743339 on upgrade, so needs some additional testing.. > If you need help with determining what certificates are used in cross > signing let me know. My general idea would be to include the removed > certificates again if they are still valid and have not been revoked by > the issuer. Thanks for the offer, I appreciate it, but we're aware of the CAs that were removed. -- Kind regards, Michael
Bug#812708: works ok on testing
On 02/25/2016 08:58 AM, Tony den Haan wrote: > That is the problem, it requires -CApath, while /etc/ssl/certs should be > default. On testing it works ok without it. Which is unrelated to the ca-certificates package - that's my point :) Feel free to open a new bug report for the openssl package describing your problem, although I would suggest that this behavior change between openssl versions in stable and testing means that feature was fixed or added between those versions. Regardless, this is not related to ca-certificates in any way. -- Kind regards, Michael
Bug#812708: works ok on testing
On 02/16/2016 11:22 AM, Tony den Haan wrote: > openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp > > on jessie: (and ubuntu lts :) > Verify return code: 20 (unable to get local issuer certificate) > > on testing: > Verify return code: 0 (ok) > This appears to be unrelated to this bug report and your command works correctly on Jessie if given a CApath. I assume this is a behavioral difference in openssl. openssl s_client -CApath /etc/ssl/certs -connect gmail-smtp-in.l.google.com:25 -starttls smtp CONNECTED(0003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mx.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- <...> Verify return code: 0 (ok)
Bug#807274: wheezy-pu: package ca-certificates/20130119+deb7u2
On 02/20/2016 06:53 AM, Adam D. Barratt wrote: > For reference, neither the above nor the message opening the bug made it > to debian-release, presumably for size reasons. Thanks for the follow up. > Looking at the diff: > > diff -Nru ca-certificates-20130119+deb7u1/debian/config > ca-certificates-20130119+deb7u2/debian/config > --- ca-certificates-20130119+deb7u1/debian/config 2014-09-24 > 12:57:57.0 -0500 > +++ ca-certificates-20130119+deb7u2/debian/config 1969-12-31 > 18:00:00.0 -0600 > > I'm assuming that wasn't intentional? This is the unintentional result of building from a clean git checkout. I'll have to pull the old generated debian/config from the existing source package. This file has since been added to the clean target. This Wheezy package is going to suffer from the same regression as in Jessie, currently. Please, leave this bug report in "moreinfo", if that's OK, or just close this and I'll open a new report. I will need to create an updated diff that includes the removed 1024-bit CA certificates, once I'm sure that's working correctly in Jessie. -- Kind regards, Michael
Bug#812708: Also affected: Baltimore CyberTrust Root used by Mailchimp
On 02/05/2016 05:49 AM, Rich wrote: subject says it all. Please provide a specific URL to test. The "Baltimore CyberTrust Root" CA may be a different issue, looking at several mozilla bugzilla tickets, but I can't tell without any detail. Thanks, Michael
Bug#812488: libsms-send-perl: After upgrade: Can't send SMS: 500 Can't connect to api.twilio.com:443 (certificate verify failed)
On 02/02/2016 02:22 PM, Tim Small wrote: #813468 is similar but impacting a different application. I did come across a patch which backports the fix included in newer versions of the upstream OpenSSL 1.0.1 branch, to the 1.0.1k derived package in Jessie. I haven't reviewed or tested the fix tho': https://gist.github.com/h-yamamo/adf44638a1a04b8e86ea Thanks for the additional info and openssl ticket number. I'm open to including the 1024-bit certificates mozilla removed and started a branch, but haven't completed this. I don't have the openssl expertise to review the patch, but it is interesting and could be a better way to handle the problem, but also it seems a new patch to openssl in stable could be more invasive. -- Michael
