<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 06/01/15 09:13, Ade Lee wrote: </div> <blockquote cite="mid:1433171618.2279.9.camel@aleeredhat.laptop" type="cite"> <pre wrap="">In the past, I suspected that we needed to do these kinds of paths so that the JVM could find the C code for the JSS JNI modules. Is that no longer true? </pre> </blockquote> Once upon a time, there were some proposed changes for JNI: <ul> <li><a href="https://bugzilla.redhat.com/show_bug.cgi?id=734590">Bugzilla Bug #734590 - Refactor JNI libraries for Fedora 16+ . . .</a></li> </ul> All of this was undone as of Fedora 19. Consequently, JSS attempts to load its 'C' code portion using the following java code: <ul> <li>jss-4.2.6-35.el7/BUILD/jss-4.2.6/mozilla/security/jss/org/mozilla/jss/CryptoManager.java /** * Loads the JSS dynamic library if necessary. * This method is idempotent. */ synchronized static void loadNativeLibraries() { if( ! mNativeLibrariesLoaded ) { try { System.load( "/usr/lib64/jss/libjss4.so" ); Debug.trace(Debug.VERBOSE, "jss library loaded"); mNativeLibrariesLoaded = true; } catch( UnsatisfiedLinkError e ) { try { System.load( "/usr/lib/jss/libjss4.so" ); Debug.trace(Debug.VERBOSE, "jss library loaded"); mNativeLibrariesLoaded = true; } catch( UnsatisfiedLinkError f ) { Debug.trace(Debug.VERBOSE, "jss library load failed"); } } } } static private boolean mNativeLibrariesLoaded = false; </li> </ul> The changes that I made only remove the LD_LIBRARY_PATH, not the CLASSPATH which must still be specified. IIRC, even earlier in the history of this product, there was code that required environment variables to locate the locations of various libraries, and as the product existed on platforms other than Linux, not all of them used 'LD_LIBRARY_PATH' for this purpose (e. g. - AIX used LIBPATH, HP-UX used SHLIB_PATH, and Windows used PATH). <blockquote cite="mid:1433171618.2279.9.camel@aleeredhat.laptop" type="cite"> <pre wrap=""> I do not see any tests below that necessarily test out JSS JNI functionality. For example, one test might be to use pki to create a client NSSDB. </pre> </blockquote> Sorry, I had also done the following test (but forgot to attach it to the original email) using the changed 'pki' script: <ul> <li>cd /root/.dogtag/pki-tomcat/ca/alias/</li> <li>pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca=user-add testuser --fullName "Test User"</li> <li>pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca-user-add testuser --fullName "Test User"</li> <li>pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" client-cert-request uid=testuser</li> <li>pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca-cert-request-review 8 --action approve</li> <li>pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca-user-cert-add testuser --serial 0x8</li> <li>pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" client-cert-import testuser --serial 0x8</li> <li># certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CA Signing Certificate - example.com Security Domain CT,c, PKI Administrator for example.com u,u,u testuser u,u,u</li> <li># certutil -d . -n "testuser" -L Certificate: Data: Version: 3 (0x2) Serial Number: 8 (0x8) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=CA Signing Certificate,O=example.com Security Doma in" Validity: Not Before: Fri May 29 20:45:46 2015 Not After : Wed Nov 25 21:45:46 2015 Subject: "UID=testuser" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: a9:cb:dd:8d:35:f9:20:af:83:85:6b:79:5e:9d:93:c0: a0:4b:2f:23:32:69:a6:b3:63:d7:d6:23:56:bf:4e:ba: 6a:db:5f:9d:33:56:86:57:c5:21:46:0e:a4:72:ad:42: a4:25:27:15:ee:8c:d2:6f:87:90:8a:95:4f:f0:5c:23: f1:69:ba:c8:5b:e6:4a:de:2f:33:f5:22:65:83:c8:ff: 88:7d:3a:99:c4:af:94:98:8a:4a:4f:a9:a4:62:4d:3c: 84:16:7b:87:0b:f4:ce:d0:77:56:17:ed:97:97:ec:c9: 32:bc:b4:7a:f5:34:ce:83:6d:9f:f5:66:a7:d0:58:7f Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 92:f7:de:a4:fe:82:8f:dc:4d:f2:9f:6b:38:6a:ce:6f: d4:60:02:eb Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: <a class="moz-txt-link-rfc2396E" href="http://pki-desktop.example.com:8080/ca/ocsp">"http://pki-desktop.example.com:8080/ca/ocsp"</a> Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Name: Extended Key Usage TLS Web Client Authentication Certificate E-Mail Protection Certificate Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 5a:b7:b6:0f:78:a4:a5:91:b6:6e:64:06:4e:9c:d3:3d: 9e:77:f9:e1:c1:e1:c7:9b:8d:ae:09:20:61:55:10:17: 47:18:a2:5d:4f:b7:47:55:eb:4e:14:90:f8:50:e0:66: 1d:4d:36:df:5c:ff:92:c8:bc:09:38:ef:49:d0:71:72: 90:07:e4:0f:10:31:fa:b9:88:8c:aa:32:4e:6d:25:78: b6:47:ac:ca:5a:2d:69:d7:80:ef:6f:f2:58:8e:1d:15: b1:e7:6e:07:4f:9a:35:f0:f5:c6:5f:04:ee:fe:4f:8d: b2:c2:39:7f:2b:c6:a8:40:de:0e:04:b9:c6:33:35:67: 04:51:84:4c:a5:11:46:c0:9e:ff:a3:56:dd:fc:6e:a2: db:bf:e7:a7:ac:45:9e:f0:f1:8a:7a:be:dc:01:82:f0: 90:14:b8:38:15:97:ad:fd:de:a9:bc:11:c8:63:05:3f: 33:8a:36:d5:b6:c8:52:17:c5:37:5f:bc:f5:1e:2a:7e: 4b:10:01:e1:9c:63:9e:83:c2:40:c6:de:f0:99:95:10: 21:6b:69:c2:4a:34:b0:67:bc:eb:e1:9b:3e:c1:dd:89: aa:6b:e6:71:72:92:0b:d8:cd:c9:a0:be:d8:28:76:e9: 06:43:0f:f7:bf:66:37:1a:be:e9:f1:38:c6:24:dd:47 Fingerprint (SHA-256): 77:F0:DD:DB:6B:35:E2:CF:3A:C1:6C:13:50:3D:60:4B:6D:DA:14:5A:3F:37:90:9B:F1:02:C8:18:C6:11:34:55 Fingerprint (SHA1): 9E:6D:E2:52:30:F7:47:1E:19:0F:26:6E:CD:D4:29:92:AA:02:5F:35 Certificate Trust Flags: SSL Flags: User Email Flags: User Object Signing Flags: User </li> </ul> <blockquote cite="mid:1433171618.2279.9.camel@aleeredhat.laptop" type="cite"> <pre wrap=""> If we still do need this, it would be nice to put in paths for Debian as well, so that they do not need to patch this. Ade On Fri, 2015-05-29 at 18:02 -0600, Matthew Harmsen wrote: </pre> <blockquote type="cite"> <pre wrap="">Please review and test the attached patch out on platforms other than 'x86_64' which addresses this issue: * PKI TRAC Ticket #1392 - Remove i686/x86_64 architecture limitations (e. g. - ppc64/ppc64le) I did apply the attached patch and build it on an x86_64 machine, and successfully tested out the following: * built, installed, and tested out a CA * built, installed, and tested out a CA console * built, installed, and tested out a TKS and TPS * built, installed, and tested out tpsclient * AtoB and BtoA _______________________________________________ Pki-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>