Warren Togami wrote:
https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00166.html Red Hat's Directory Server team wants to add JSS to Fedora. But this is currently blocked, because the JSS JAR must be signed by an upstream key. This is currently not permissible under Fedora Packaging Guidelines for a few reasons:- The binary signed by an external source is not built by us.- We cannot build an exact duplicate in Fedora from sources (because of the binary signature.) - Distribution of a signed binary could be in violation of the spirit, if not the letter of FOSS licenses or Free Software Guidelines. This may also become automatically incompatible with the GPLv3. I am not a legal expert so I don't fully understand the implications of this.
Here is a bit more information on this.JSS is, among other things, a Java Cryptography Extension (JCE) provider. This means that it provides cryptographic algorithms (block ciphers, etc).
Sun requires all JCE providers to be signed by a Sun-issued X.509 certificate. This is partly for export reasons as well as to provide a level of confidence that the implemented provider you are using to perform your crypto operation is trusted. For more information on JCE/JCA see http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html
One can request a signing cert from Sun at: http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CertForm.txtFedora could likely get one of these certificates but then we'd have to find a way to protect the key material and still allow the JAR to be signed.
The bottom line is that if the jar isn't signed and someoone tries to use the JCE classes in JSS they will fail with a nasty error message like:
java.security.NoSuchProviderException: JCE cannot authenticate the provider Mozilla-JSS
at javax.crypto.SunJCE_b.a(DashoA6275) at javax.crypto.SunJCE_b.a(DashoA6275) at javax.crypto.SecretKeyFactory.getInstance(DashoA6275) at org.mozilla.jss.tests.HMACTest.main(HMACTest.java:140)Caused by: java.util.jar.JarException: file:/usr/share/java/jss4-4.2.4.jar has unsigned entries - org/mozilla/jss/CRLImportException.class
at javax.crypto.SunJCE_d.b(DashoA6275) at javax.crypto.SunJCE_d.a(DashoA6275) at javax.crypto.SunJCE_d.a(DashoA6275) at javax.crypto.SunJCE_b.b(DashoA6275) ... 4 more
How do we handle this situation? --------------------------------------------------------------- 1) Build and Compare to At Least Prove Reproducible Equivalence ---------------------------------------------------------------https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00311.html I theorized that it might be OK if we build the binary in Fedora, and compare it to the signed binary. If they match fully (except for the signature) then equivalence is proven. Throw away the built binary and use the signed binary in the payload RPM.https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00313.htmlBut this method is most likely not technically feasible. It is also doubtful that this would qualify as Free Software. --------------------------------------------------------------- 2) Do Not Sign the Jar? --------------------------------------------------------------- - Only local applications would use JSS.- Those local applications (or the Java stack under it) could somehow choose to ignore the JAR's signature. - We shouldn't worry about this, because JSS (and those local apps) would be distributed themselves in signed RPMS.Only apps controlled by Red Hat may be able to use an unsigned JSS, by using JSS directly instead of going through JCA. This makes it fine for Fedora, RHEL and other flexible FOSS software, but 3rd party apps might not be compatible.Theoretically, 3rd party apps could use a second copy of the JSS JAR that is the upstream signed binary. Red Hat could even provide that somewhere on the side so users have something consistent. It just wont ship in Fedora proper.So, two JSS JAR's are possible for parallel install. - FOSS JSS (unsigned) - JSS (signed, but not in Fedora) Discuss feasibility? Warren Togami wtogami@xxxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
