Bug 448497

Notes:

1) we'll want to add "Conflicts: openssl < blah" to this I suppose.
2) the /etc/pki/tls and .../certs directories will become dual-owned by openssl
and ca-certificates, but this doesn't seem too bad/is inevitable
3) does the java/cacerts file have to be a different directory?  I'd vaguely
prefer it to be at something like /etc/pki/tls/certs/ca-bundle.javadb

1) About the conflict - I'm not sure - There will be implicit conflict with the
old openssl anyway and the rule about the no implicit conflicts in packages
applies to current versions in Fedora. So I think it is unnecessary to add it.

2) is OK

3) is IMO OK as is (/etc/pki/java/...) it makes it clear that it is used for
java apps.

How do you create the ca-bundle.crt file? Could/should it be created from the
original Mozilla source file in the %build?

Isn't the build requirement on java-1.6.0-openjdk too specific? Could just
Buildrequires: java-openjdk or Buildrequires: /usr/bin/keytool be used instead?

(In reply to comment #2)
> 1) About the conflict - I'm not sure - There will be implicit conflict with the
> old openssl anyway and the rule about the no implicit conflicts in packages
> applies to current versions in Fedora. So I think it is unnecessary to add it.

OK.

> How do you create the ca-bundle.crt file? Could/should it be created from the
> original Mozilla source file in the %build?

It's created in the same way as before; an off-line run of the mkcabundle.pl
which extracts the data from the certdata.txt in Mozilla CVS.  Not sure what the
advantage of putting the certdata.txt directly into CVS would be.

> Isn't the build requirement on java-1.6.0-openjdk too specific? Could just
> Buildrequires: java-openjdk or Buildrequires: /usr/bin/keytool be used 
> instead?

Tom F?  Using /usr/bin/keytool worked for me.

(In reply to comment #3)
> > How do you create the ca-bundle.crt file? Could/should it be created from the
> > original Mozilla source file in the %build?
> 
> It's created in the same way as before; an off-line run of the mkcabundle.pl
> which extracts the data from the certdata.txt in Mozilla CVS.  Not sure what the
> advantage of putting the certdata.txt directly into CVS would be.

Does the mkcabundle.pl pull the file directly from the CVS?
IMO all the automated steps leading from the original source to the final
ca-bundle.crt should be included in the %build so anyone can reproduce the
process and see where the certificates originate from. If the mkcabundle just
pulls the source from CVS it should at least be included in the src.rpm so
anyone can reuse it to generate a fresh bundle.

(In reply to comment #4)
> Does the mkcabundle.pl pull the file directly from the CVS?

Yup.

> IMO all the automated steps leading from the original source to the final
> ca-bundle.crt should be included in the %build so anyone can reproduce the
> process and see where the certificates originate from. If the mkcabundle just
> pulls the source from CVS it should at least be included in the src.rpm so
> anyone can reuse it to generate a fresh bundle.

Yeah, good idea.

Spec URL: http://jorton.fedorapeople.org/cacerts/ca-certificates.spec
SRPM URL: http://jorton.fedorapeople.org/cacerts/ca-certificates-2008-2.src.rpm

* Tue May 27 2008 Joe Orton <jorton> 2008-2
- add (but don't use) mkcabundle.pl
- tweak description
- use /usr/bin/keytool directly; BR java-openjdk

rpmlint -v ../SRPMS/ca-certificates-2008-2.src.rpm 
ca-certificates.src: I: checking
ca-certificates.src: W: no-%prep-section
Add empty %prep section perhaps?

ca-certificates.src: W: strange-permission mkcabundle.pl 0775
ca-certificates.src: W: strange-permission generate-cacerts.pl 0600
Please change the permissions to 0755 on both files.

rpmlint -v ../RPMS/noarch/ca-certificates-2008-2.noarch.rpm 
ca-certificates.noarch: I: checking
ca-certificates.noarch: W: no-documentation
This is OK.

ca-certificates.noarch: W: non-conffile-in-etc /etc/pki/java/cacerts
ca-certificates.noarch: W: non-conffile-in-etc /etc/pki/tls/certs/ca-bundle.crt
The file list must be fixed. Both files should be %config(noreplace) so the
administrator can modify them and not get them overwritten on upgrade.

Spec URL: http://jorton.fedorapeople.org/cacerts/ca-certificates.spec
SRPM URL: http://jorton.fedorapeople.org/cacerts/ca-certificates-2008-3.src.rpm

* Tue May 27 2008 Joe Orton <jorton> 2008-3
- fix source script perms
- mark packaged files as config(noreplace)

Oh, and -3 added an empty %prep too ;)

(In reply to comment #1)

> 3) does the java/cacerts file have to be a different directory?  I'd vaguely
> prefer it to be at something like /etc/pki/tls/certs/ca-bundle.javadb

My only concern is that some crazy Java apps may completely follow the symlink
then check the file name.  Other than that (probably unlikely) problem, I'd
prefer to keep the cacerts name for familiarity to Java administrators.  I'm
fine with changing the location though.

This is slightly unrelated but I thought I should note my concern here.  Eclipse
sometimes completely follows symlinks to look up locations of files within the
JRE directory layout.  For example, it might follow the /usr/bin/java symlink
directly to find the directory where the real binary is located, then look for
another file relative to that directory.  This is the only potential
compatibility problem I can foresee by symlinking to an external cacerts file. 
But I can't see a good way to address this, and the benefits of an external
cacerts file seem to outweigh this unlikely-to-be-hit incompatibility.

> > Isn't the build requirement on java-1.6.0-openjdk too specific? Could just
> > Buildrequires: java-openjdk or Buildrequires: /usr/bin/keytool be used 
> > instead?
> 
> Tom F?  Using /usr/bin/keytool worked for me.

Yes, requiring java-openjdk is better.  I specified the openjdk-specific path in
case /usr/bin/keytool, an alternatives-managed symlink, points to
java-gcj-compat's gkeytool which won't work.  That said, this wouldn't be a
concern in koji builds since java-1.5.0-gcj won't be installed there.  It's
probably fine (and definitely simpler) to just run /usr/bin/keytool.

Hmm, actually the %prep won't be empty - you should remove the java directory
there otherwise subsequent builds of it with rpmbuild will fail (not in mock of
course). I'd also suggest to rename the java directory to something more
meaningful such as ca-certificates so it is clear where it comes from when
looking at the SOURCES dir.

Spec URL: http://jorton.fedorapeople.org/cacerts/ca-certificates.spec
SRPM URL: http://jorton.fedorapeople.org/cacerts/ca-certificates-2008-4.src.rpm

* Tue May 27 2008 Joe Orton <jorton> 2008-4
- use package name for temp dir, recreate it in prep

Did you want to eliminate the java directory and relocate cacerts under
/etc/pki/tls/certs/?  That would be fine by me (as long as the cacerts name
stays the same).  I just need to know where to link.

Do existing packages depend on the existence of /etc/pki/java/cacerts?  If so
then let's not bother and just leave it there.

The plan is to symlink $JAVA_HOME/jre/lib/security/cacerts to
/etc/pki/java/cacerts so the location of cacerts doesn't really matter.

The only situation in which it would matter would be if an app assumed that
cacerts was under $JAVA_HOME, dereferenced it fully, then looked for another
file relative to that.  But cacerts should be under /etc and not under JAVA_HOME
because 1) it's a config file, 2) it should (ideally) be shared by all JREs on
the system.  I don't have a good solution for the lookup-relative-to-cacerts
situation, so I'll just have to hope that no app does that.  (Having
ca-certificates provide
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/security/cacerts directly
wouldn't work due to the versioned directory and for other reasons).

So basically, it doesn't matter to me if it's /etc/pki/java/cacerts or
/etc/pki/tls/certs/cacerts.

Created attachment 306845 [details]
generate-cacerts.pl patch to solve broken pipe errors

This patch eliminates these errors:

yes: standard output: Broken pipe
yes: write error

I prefer /etc/pki/java/cacerts as in the current src.rpm.

rpmlint -v ca-certificates-2008-4.src.rpm
ca-certificates.src: I: checking
ca-certificates.src: W: strange-permission mkcabundle.pl 0755
ca-certificates.src: W: strange-permission generate-cacerts.pl 0755
OK as these are scripts.

rpmlint -v ca-certificates-2008-4.noarch.rpm
ca-certificates.noarch: I: checking
ca-certificates.noarch: W: no-documentation
OK

The package seems to be fine now. 

APPROVED

Please include the updated generate-cacerts.pl from the previous comment when
importing into CVS.

Also please notify me as soon as the package is built in rawhide (and F9 if you
want to include it there too) and I will update openssl accordingly - I'll drop
the ca bundle from there and add Requires: ca-certificates.

New Package CVS Request
=======================
Package Name: ca-certificates
Short Description: The Mozilla CA root certificate bundle
Owners: jorton,tmraz
Branches: 
InitialCC:
Cvsextras Commits: no (rationale: this is a highly security-sensitive package) 

Can this package be added to Fedora 9?  It would allow us to fix

https://bugzilla.redhat.com/show_bug.cgi?id=444260

with an update.

cvs done.

This package seems to be included in Fedora 10. I'm assuming this ticket can and should be closed, so I'm doing that, but please reopen if I'm wrong.