Bug#962669: Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
Hi Michael,
On Fri, 2020-06-12 at 08:21 -0500, Michael Shuler wrote:
>
> On 6/12/20 7:36 AM, Adrian Bunk wrote:
> > On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote:
[...]
> > > > Wouldn't embedded setups be more likely to have a hard-coded
> > > configuration?
> >
> > The official way to hardcode CA configuration would be through
> > debconf or /etc/ca-certificates.conf, which runs into #743339.
> >
> > If you are really security-focussed you might pin the actual
> > certificate instead of trusing a CA.
Sadly that doesn't seem to work with a lot of tools these days.
> > For the average embedded device the only thing that matters about
> > ca-certificates is something like "https works".
> >
> > > > Would it work to force-enable them in /etc/ca-certificates.conf
> > > > from the preinst when upgrading from old-version matching
> > > > 20200601* ?
> >
> > This could actually be done in the postinst before the debconf
> > configuration, something like
> > sed -i
> > "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt
> > |" /etc/ca-certificates.conf
> > for all affected certificates when $2 matches 20200601*
>
> This is what I was working on last night, there is an old dpkg
> --compare-versions example in postinst, and that is similar to the
> action I had in mind. I intend to sed all in the list we
> blacklisted, since they remain in the bundle, so we're not here next
> week with another of the date or intermediate exceptions in NSS. If
> there is objection to this, please let me know.
>
> > > I'll leave the technical answer to Michael.
> > >
> > > Practically, it's then not great for users who had intentionally
> > > removed the certificates - or simply decided not to trust them in
> > > the first place - prior to the upgrade. I'm not sure how we could
> > > distinguish the cases automatically.
> >
> > The default is to trust all new certificates, so this is what the
> > vast majority of users are using.
> >
> > #743339 is primarily about this kind of remove+readd in the package
> > being the only way how any installed certificate could end up being
> > deactivated in the default situation.
> >
> > This is permanent damage that can lead to nasty problems months or
> > years later.
> >
> > There are likely some users somewhere who have manually activated
> > or deactivated these specific certificates, but this is nothing we
> > can handle correctly in both directions now.
>
> This is exactly the kind of behavior I think we'd like to preserve,
> so we don't stomp on a previous intentional trust setting and
> blindly enable, but I think this specific list of blacklisted certs
> being re-enabled, if specifically 20200601* is installed should work.
> The default "yes" trust and re-enable of these may be the "good
> enough" fix, while #743339 is still an issue. That should hit way
> over 80% use case, if we consider an 80/20 split.
>
> For what it's worth, with additional testing after this, I believe I
> may have found one of the "save but disable' causes of #743339,
> after staring at ca-certificates.conf creation, upgrades, etc in
> postinst and the debconf ca-certificates.config contents. It won't
> fix existing trust ^!'s, but would help on future root removals -
> later on that bug..
>
> > > > Unrelated to that, please keep the Python 2 -> 3 build
> > > > dependency
> > > > change out of this emergency update.
> > >
> > > ACK.
>
> Will do, thank you both.
How are things looking with the new update?
Regards,
Adam
Reply to: