On 2018-06-13 00:10:57 [+0200], Axel Beckert wrote: > Hi Sebastian, Hi Axel,
> Sebastian Andrzej Siewior wrote: > > > I don't think so unless a future upload of OpenSSL to unstable fixes > > > this. The recent one to unstable didn't. > > > > forwarded https://github.com/openssl/openssl/issues/6475 > > > > Just a little question: The missing certificates: > > |rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file > > |rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file > > |rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file > > |rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file > > > > where are they from? > > From the ca-certificates package I assume. At least those errors go > away if I downgrade to 20170717 again and they reappear as soon as I > upgrade to 20180409 on that machine. At least the file names are the > same as in my mail from 12th of April[1] (just in different order). > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895482#10 > > I just checked: All four CAs are CAs I've chosen to be enabled. But > they're by far not the only CAs which are enabled from ca-certificates > on that machine. So I have no idea what makes those four special. Okay. So this is "normal" debconf and nothing more. Just wanted to make sure. > > Is there something specific you did to get those > > symlinks which now don't belong to a real file? > > No. As mentioned in the initial report, I have ca-certificates to ask > me every time on new CAs if I want to enable them or not. And I'm > rather conservative with enabling CAs. I also do this on most of my > machines, usually with slight differences in the list of enabled CAs. > Nevertheless this only happened on two of my machines. I asked upstream what they thing about ignoring these errors because the perl script does so. On the other hand what about cleaning up these dangling symlinks? > Regards, Axel Sebastian
