7:02 p.m.
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) <https://fedorahosted.org/pki/ticket/1392>
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
10:13 a.m.
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?
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.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
11:49 a.m.
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+ . . .
<https://bugzilla.redhat.com/show_bug.cgi?id=734590>
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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
3654
days inactive
3656
days old
2 comments
2 participants
participants (2)
-
Ade Lee -
Matthew Harmsen