On Tue, 2008-06-03 at 22:09 +0200, Pierre Schmitz wrote: > Am Montag 02 Juni 2008 02:43:19 schrieb Dan McGee: > > Is this maybe even core/support material? > > I am still undecided how to handle this. We have several options: > > 1) Make ca-certificates a depend of openssl. This will restore the behaviour > before the openssl project removed their own certs. Those packages using > their own bundle (like curl) should be update to use this one instead. > 2) Add this package as a dependency to browser and other appy which use > openssl > 3) Don't do anything and put it as an optional package into extra > > As I said I have no strong oppinion about this. Maybe option 1 would be the > best because it does not change the current behaviour too much and browsers > wouldn't complain about untrusted certs when the new openssl package is moved > to core.
Option 1 looks good to me. Note that browsers usually have their internal ca certificates included. Mozilla products store them in the nss library, kdelibs contains its own ca-bundle.crt in /opt/kde/share/apps/kssl/. Option 2 is required for anything that installs its own ca-bundle. Examples of these are curl, kdelibs, java-gcj-compat and nss. The last two of these require hooks in /etc/ca-certificates/update.d/ to regenerate their certificate database on any change/update to ca-certificates.
