On 06/01/15 09:13, Ade Lee wrote:

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?

Once upon a time, there were some proposed changes for JNI:

Bugzilla Bug #734590 - Refactor JNI libraries for Fedora 16+ . . .

All of this was undone as of Fedora 19.

Consequently, JSS attempts to load its 'C' code portion using the following java code:

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.
     * <p>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;

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).

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.

Sorry,

I had also done the following test (but forgot to attach it to the original email) using the changed 'pki' script:

cd /root/.dogtag/pki-tomcat/ca/alias/
pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca=user-add testuser --fullName "Test User"
pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca-user-add testuser --fullName "Test User"
pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" client-cert-request uid=testuser
pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca-cert-request-review 8 --action approve
pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" ca-user-cert-add testuser --serial 0x8
pki -d . -C /root/.dogtag/pki-tomcat/ca/password.conf -n "PKI Administrator for example.com" client-cert-import testuser --serial 0x8
# 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
# 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: "http://pki-desktop.example.com:8080/ca/ocsp"

            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

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:

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
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel