Cyril Brulebois <[email protected]> (2026-10-22): > Where and how to go from here isn't entirely clear to me at this point. > > Wild guess, if we still need that manual copy/deployment in this > specific location, we could still have some kind of cleanup some > finish-install script, that would get rid of all files that are > (currently) shipped by ca-certificates, so that we only keep any “really > local” certificates in there on the long run? > > Also, maybe I could have caught that when I hacked together commits > ee95d8a89a0a and 7a79b4556436… :( Is deploying ca-certificates at this > point sufficient to make the manual copy of the whole directory's > contents moot?
Of course, this is merely about trying to prevent this issue from happening in future d-i releases… As for remediating the issue on already-deployed systems, should there be something (in ca-certificates?) that would get rid of certificates that are known to be problematic? Something like using the blocklist for /usr/local/ as well? It's been a long while since I last looked at implementation details, so I'm not sure whether that'd be easily doable (or doable at all), even if there was a consensus. (All of this reminds me that there wasn't much feedback on #1142266, which is another story yet somewhat related.) Cheers, -- Cyril Brulebois ([email protected]) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
