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
Maybe a "good enough" fix will have to do for the specific ones
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
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
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.
Will do, thank you both.