ca-certificates installs about 100 certificates into
/etc/ssl/certs. However, these are not actually dropped into the
directory; instead, symlinks into /usr/share are put in place:
piper:/etc/ssl/certs# ls -la /etc/ssl/certs/cacert.org.pem
lrwxrwxrwx 1 root root 52 2006-10-31 18:56 /etc/ssl/certs/cacert.org.pem -> /usr/share/ca-certificates/cacert.org/cacert.org.crt
Since #350282 is still being discussed, I ended up doing
cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem
on systems that needed access to all of CACert's certificates.
The recent ca-certificates upgrade overwrote this "configuration"
simply because my /bin/cat call actually changed a file in
/usr/share, where changes by the admin are not preserved. Yet, due
to the links in /etc/ssl/certs, the admin is given the impression
that these are configuration files and can thus be edited according
to Debian's holy conffile handling policy.
I consider this a bug, and even release-critical, and would say that
ca-certificates should use ucf to maintain the certificates in
/etc/ssl/certs. Arguments against that are to keep /etc small, but
at 444k I don't see ca-certificates being a culprit.
Comments?
Please don't tell me to use an editor that writes a new inode when
changing files. It's not a solution to the problem, even though it
would address the symptom.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"when faced with a new problem, the wise algorithmist
will first attempt to classify it as np-complete.
this will avoid many tears and tantrums as
algorithm after algorithm fails."
-- g. niruta
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)