[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pki-devel] [PATCH] Remove i686/x86_64 architecture limitations (e. g. - ppc64/ppc64le)



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:

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]