[cp-patches] Re: RFC: add a cacerts file under
mark at klomp.org
Wed Jun 7 18:14:44 UTC 2006
I CCed the devjam list on which a couple of different distribution
packagers are subscribed. Devjam people, Raif added support for
importing trusted ca-certs to GNU Classpath so our tls/ssl
implementation for example can just reuse the ca-certs that are already
packaged for an distribution (for example those used by Mozilla).
Feedback on how to make this as easy as possible for distros appreciated
(see below). Please forward to any distro-list when appropriate.
On Fri, 2006-06-02 at 06:19 +1000, Raif S. Naffah wrote:
> On Monday 29 May 2006 21:21, Mark Wielaard wrote:
> > On Mon, 2006-05-29 at 21:00 +1000, Raif S. Naffah wrote:
> > > On Monday 29 May 2006 20:02, Mark Wielaard wrote:
> > > > On Mon, 2006-05-22 at 21:42 +1000, Raif S. Naffah wrote:
> > > > > my question is: does anybody see any problem, legal or
> > > > > otherwise, in including our version of this cacerts file which
> > > > > i named "cacerts.gkr" into the GNU Classpath distribution?
> > > >
> > > > I wonder how well that will work with the various distributions.
> > >
> > > if by distributions you mean the different VMs that use Classpath
> > > then this file is not much different than for example
> > > classpath.security, which is our version of java.security.
> > No, I was thinking of the GNU/Linux distros. They seem to have their
> > own collection of "trusted" ca-certs already. So I was wondering
> > whether we could somehow reuse those easily (for example during
> > installation time). That way a user has only one set of ca-certs to
> > worry about. Since at least for Debian it seems every package using
> > ssl uses the same set. http://packages.debian.org/ca-certificates
> > And then we wouldn't have to worry which certificates to include and
> > where they would come from.
> i downloaded and installed (own --prefix since i don't use a Debian
> distro) the latest stable ca-certificates package (from
Devjam people. Hints on how other distros handle this appreciated.
> i also added CACertCmd as a new command to the keytool --which does not
> have a counter-part in the RI version-- to import without prompting the
> user one x.509 certificate from a designated file. this new command is
> invoked through: keytool -cacert ...
> a script, import-cacerts.sh, added to the scripts folder, recursively
> visits a given directory invoking the keytool -cacert command on each
> file with the following:
> * the alias of the certificate is constructed from the file name.
> * the key store password is hard-wired to 'changeit' --similar to the RI
> * the key store is hard-wired to cacerts.gkr in resource/java/security.
Very nice! Please do check this in.
> all this allows us to build/update a key store of trusted certificates,
> which can then be included in our deliverables. the new '-cacert'
> command, although specific to our version of keytool is useful for
> sysadmins who may want to use something similar in their environment.
This seems perfect to let our users decide which cacerts they want to
use themselves. If it all possible I would like to not actually ship any
"trusted" ca-certs ourselves since that would put us in the position to
decide which ca-certs are actually trusted and when to deprecate which
ones for each release. So I would like to add a configure option (say
--with-ca-cert-dir=/path/to/ca/cert/dir) which can be used by the
user/packager to automatically run the import-cacerts.sh script during
Ideally each distribution would then add some package hooks to rerun
import-cacerts.sh for classpath whenever the ca-certificates package is
updated. I assume something like this is also used for Mozilla or
OpenSSL. Devjam people?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060607/8565832a/attachment.pgp
More information about the Classpath-patches