Bugzilla Bug 177397

/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.

*** Bug 177725 has been marked as a duplicate of this bug. ***

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.