Bug#962669: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1

[Michael Shuler <michael@pbandjelly.org>]

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