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
