/etc/ssl/certs/cacert.org.pem -> /usr/share/ca-certificates/cacert.org/cacert.org.crt ls -l /usr/share/ca-certificates/cacert.org/ class3.crt root.crt Reproducible: Always
i dont think i'll bother fixing this in our ebuild since it doesnt cause any harm
*** Bug 177702 has been marked as a duplicate of this bug. ***
Reopen wrt Bug 177702
When postfix mail system is used with Cacert.org certificates, it is impossible to send an email when TLS authentication is used. It also breaks stable (x86) boxes.
*** Bug 177725 has been marked as a duplicate of this bug. ***
read this report wrt "breaking" things like postfix: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413766
I guess my initial post wasn't clear, I should have specified better but I was in a hurry sorry. To me nothing gets broken, and I think it'd be safer if people who uses those cerfificates directly would copy them in their own /etc/postfix/ or /etc/apache2 directories. Also I don't see why they link the root certificate in their configurations, they should need only their own private key and relative certificate, not the cert from the authority that is instead needed by the clients to check the signature. So I don't care if you add a backwards compatible copy or not, I think it's cleaner not to do that. To me the problem is that totally useless garbage is left in that directory, and I would like some more automation instead of having to clean it up by hand every time with symlink -d. I don't know about you, but I like my systems not to accumulate garbage over time. It's not a disk space problem. If you think it's unsafe to clean the dangling symlinks by default, I would like at least one use flag to clear those dangling symlinks automatically post-installation. Calling symlink -d /etc/ssl/certs would be enough, however it requires the symlink package, otherwise you need to script it a bit more than one line. If you sill prefer to leave the garbage accumulate there, that's fine with me too, it was just a suggestion. Thanks.
Basically I noticed this because cacert.org's cert files were broken into root.crt and class3.crt. Now you run update-ca-certificates in the pkg_postinst() step, however since the file is being installed into /etc it's under CONFIG_PROTECT. So the update to the config file doesn't actually occur until the user runs etc-update or dispatch-conf. However, you've already run update-ca-certificates, which now results in the old file being used and the user sees cacert.org's certificates silently disappear for them. So basically the way you're currently installing, cacert.org will disappear forever for users. Unless they first do etc-update and then run update-ca-certificates. This needs to be rectified.
*** Bug 180512 has been marked as a duplicate of this bug. ***
how to fix manually ? update-ca-certificates does not. Is there a particular order or emerge, etc-update and update-ca-cert to get things fixed ? doug seems to have an idea on this. Once we got a list, maybe we could just put the process in an ewarn ..
I should we should add /etc/ca-certificates.conf to CONFIG_PROTECT_MASK, so that update-ca-certificates does not need to depend on etc-update being run. Any objections?
doesnt matter to me
ca-certificates-20080514-r1 is in the tree with the fix for this now.
