[Pkg-freeipa-devel] [Git][freeipa-team/jss][master] 33 commits: Add Fedora 33 to CI

Timo Aaltonen gitlab at salsa.debian.org
Sat Oct 31 17:27:33 GMT 2020 


Timo Aaltonen pushed to branch master at FreeIPA packaging / jss


Commits:
dba06409 by Alexander Scheel at 2020-08-20T09:59:54-04:00
Add Fedora 33 to CI

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
731650ba by Alexander Scheel at 2020-08-20T09:59:54-04:00
Always attempt to pull a newer base image

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
33eafcca by Alexander Scheel at 2020-08-20T09:59:54-04:00
Switch to Fedora registry for Fedora-based images

This is updated more frequently than Dockerhub, which `docker` in CI
will default to.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
1f203722 by Alexander Scheel at 2020-08-31T17:29:34-04:00
Add NSS stubs for BadCertHandler

The JDK's SSL interfaces under javax.net.ssl do not provide a way for
the SSLSocket/SSLEngine instance to validate hostname during the
handshake. Instead, the accepted way of doing hostname verification
(using a HostnameVerifier) is after the handshake is completed. This
causes problems with NSS, because they assume the hostname is available
for validation at handshake time.

In order to support this use case, when the hostname is `null` on a
client SSL socket, we will attach using SSL_BadCertHook and give the
JSSEngine a chance to bypass this value.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
a7b43ee2 by Alexander Scheel at 2020-08-31T17:29:34-04:00
Add SSLErrors with SSL_ERROR_BAD_CERT_DOMAIN

This is the only SSLError we wish to allow through in regular JSSEngine
client operations.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
fe75335b by Alexander Scheel at 2020-08-31T17:29:34-04:00
Bypass SSL_ERRORS_BAD_CERT_DOMAIN for JDK

When JSSEngine is used via the provider interface, most callers won't be
aware that they're using JSSEngine. As a side effect, they won't be
using JSSEngine's setHostname() to validate the server's SSL
certificate. This means NSS has no knowledge of the hostname, throwing
an error like:

    Caused by: javax.net.ssl.SSLHandshakeException: Error duing SSL.ForceHandshake() :: SSL_ERROR_BAD_CERT_DOMAIN (-12276)
            at org.mozilla.jss.ssl.javax.JSSEngineReferenceImpl.updateHandshakeState(JSSEngineReferenceImpl.java:856)
            at org.mozilla.jss.ssl.javax.JSSEngineReferenceImpl.unwrap(JSSEngineReferenceImpl.java:1037)
            at org.mozilla.jss.ssl.javax.JSSSocketChannel.read(JSSSocketChannel.java:272)

We need to provide a mechanism to bypass this by default for these
connections, in order to stay compatible with the JCA. This approach was
suggested by Bob Relyea.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
d0c8b245 by Alexander Scheel at 2020-09-02T10:28:51-04:00
Disable ENABLE_FALLBACK_SCSV for JCA compatibility

While ENABLE_FALLBACK_SCSV is present in most browsers, it isn't
generally suitable for use in a library by default because connected
applications might use different TLS versions than this library. This
will result in breakage when downgrading TLS versions would usually be
fine (such as TLSv1.2 from TLSv1.3). Additionally, JCA providers don't
set this option by default.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
0857629c by Alexander Scheel at 2020-09-02T10:28:51-04:00
Add Post-Handshake Auth to legacy SSLSocket

When TLSv1.3 was introduced into the legacy SSLSocket prior to the
introduction of JSSEngine, we didn't add support for PHA. This only
requires adding a single option, SSL_ENABLE_POST_HANDSHAKE_AUTH, and
allowing the user to control whether or not it is enabled. Enabling this
option brings compatibility with TLSv1.2's rehandshakes for identifying
the user after the initial request. Because Tomcat uses this upgrade
path (for an application with mixed authenticated and non-authenticated
endpoints), we need to support it in SSLSocket.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
419a1cd7 by Alexander Scheel at 2020-09-02T20:40:50-04:00
Fix JNI function misname

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
b2a33446 by Alexander Scheel at 2020-09-10T16:17:46-04:00
When hostname is missing, set BAD_CERT_DOMAIN

This fixes a bug with the BadCertHook that we recently introduced: when
no hostname is set, NSS sets SSL_ERRORS_BAD_CERT_DOMAIN, but our custom
callback didn't. This meant it would pass the last seen error back up to
the caller, even though we meant to set this instead.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
25ca993c by Alexander Scheel at 2020-09-10T16:17:46-04:00
Add additional inline documentation to JSSEngine

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
37543cc7 by Alexander Scheel at 2020-09-10T16:17:46-04:00
Add CryptoManager.isInitialized()

This prevents Java from thinking we're trying to recursively load the
JSSProvider. We kinda are, but we just really need to trigger it to load
in more instances.

In particular, in JSSProvider, we need to check if CryptoManager is
already initialized, and if not, initialize it. We used
CryptoManager.getInstance() for this, which in turn tries to load the
provider if it isn't already loaded. This resulted in a recursive
initialization. By using CryptoManager.isInitialized(), we can avoid the
call to CryptoManager.getInstance() and avoid this recursion.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
f10c7b96 by Alexander Scheel at 2020-09-10T16:17:46-04:00
Add SNI to all socket connections

One limitation of NSS's SSL APIs is that client sockets cannot indicate
SNI information except via SSL_SetURL(). The downside with this approach
is that the same hostname is also used for certificate validation. In
particular, Java doesn't expose the hostname for certificate validation,
but only exposes one hostname in the SSLEngine constructor. This means
we shouldn't usually use this hostname for certificate validation, but
only for SNI.

However, some servers require SNI in order for the connection to
succeed. One example at the time of writing is google.com. By using
SSL_SetURL, we both validate the certificate and provide SNI, which is
sufficient in most instances. However, in the event the hostname is
incorrect for certificate validation, a BAD_CERT_DOMAIN error will still
raise, triggering our other checks, and return control back to Java's
hostname validation logic.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
1244bb0c by Alexander Scheel at 2020-09-10T16:17:46-04:00
Fix parameters on unwrap() buffer copy

When reading data from NSS during unwrap(), we get the result back as a
single byte array. However, the caller already has separate ByteBuffer
instances that we need to put data into. Because the loop incremented
the index again, we returned one extra byte. This resulted in the
JSSEngine caller thinking there was one more byte of data, usually a
NULL byte. When multiple HTTPS requests were issued on a single TLS
connection, this resulted in the caller getting a single NULL byte
between requests, causing HTTP parsing libraries to throw an
exception.

Fixing the array bounds and returning the correct size fixes the
problem.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
05075c6d by Alexander Scheel at 2020-09-10T16:17:46-04:00
Test bytes produced/consumed in SSLEngine

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
db5eaaf6 by Alexander Scheel at 2020-09-10T17:22:58-04:00
Add documentation about CryptoManager/JSSProvider

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
2e693d52 by Alexander Scheel at 2020-09-17T14:03:42-04:00
Port from Apache Commons Lang 2 -> 3

Credits: Fabio "decathorpe" Valentini

Resolves: #621

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
72a75fba by Alexander Scheel at 2020-09-18T10:15:12-04:00
Bump JSS version to v4.8.0 alpha 1

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
6c40ee99 by Alexander Scheel at 2020-09-18T16:41:14-04:00
Finish releasing slots after use

Slots in NSS are reference counted; it is important to release our copy
of the reference when we're done using it. This fixes various instances
of slots either not being released or being released in the wrong order.

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
7207f9da by Alexander Scheel at 2020-10-05T10:27:00-04:00
Move issue reports from Pagure to GitHub

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
eefb1d98 by Endi S. Dewata at 2020-10-06T16:01:47-05:00
Update .classpath

- - - - -
3fa5c8cd by Fraser Tweedale at 2020-10-12T09:25:57-04:00
Fix missing OIDMap mappings for X.509 extensions

I was getting a very strange error in JSSTrustManager certificate
validation.  The leaf certificate was (wrongly) being rejected for
not having the id-kp-serverAuth EKU.

I traced the error to X509CertImpl.getExtensionValue(); in
particular its catch block.  Upon exception it discards the
exception and returns null.  (This is not unreasonable when e.g. the
extension data cannot be parsed).  I added some debug logging.  The
exception thrown was:

  java.security.cert.CertificateParsingException: Invalid root of
      attribute name, expected [x509], received [ExtendedKeyUsageExtension]
    at ...X509CertImpl.get(X509CertImpl.java:499)
    at ...X509CertImpl.getExtensionValue(X509CertImpl.java:1014)

>From here I traced it to the OIDMap and the String names.  Whereas
most extension names in the OIDMap had a prefix of
"x509.info.extensions.", three did not, including
ExtendedKeyUsageExtension.  getExtensionValue() looks up the name in
the OIDMap by OID, then uses it to index into internal structures to
return the datum suggested by the OID.  Reinstating the prefix in
the OIDMap resolved the issue.

Apart from EKU the two other affected extensions are Subject
Directory Attributes and Certificate Policies.  Why the prefixes
were omitted for these three extensions is lost in time.  This code
was moved from Dogtag to JSS relatively recently, but the code was
like this in the first commit in Dogtag's repo, from 2008.

I believe there is a low likelihood of regression from this change.
As far as I can tell, the only classes that use the result of
OIDMap.getName() in a logical process are X509CertImpl and friends
X509CRLImpl and RevokedCertImpl.  It is also used in ExtPrettyPrint
but only for pretty-printing.

- - - - -
ac245c43 by Alexander Scheel at 2020-10-15T12:57:10-04:00
Update minimum NSS version in README

Resolves: #645 reported by @cosarara

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
9ece51b7 by Alexander Scheel at 2020-10-27T10:23:01-04:00
Log exceptions when libjss4.so failed to load

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
3e489fe3 by Fraser Tweedale at 2020-10-28T09:56:50-04:00
JSSSocketChannel.read: deliver all data from buffer fd

JSSSocketChannel.read() returns 0 when the underlying socket does
not yield any new data.  But in the case of small output buffers,
earlier invocations of read() may result in more decrypted data
sitting in the unwrapped side of the j_buffer, never to be
delievered to the application.

To resolve this issue, continue on to unwrap() even when the
underlying socket does not yield new data.

However, only do this after the handshake has been completed.
Empirically, calling unwrap() at early stages of the handshake with
empty buffers breaks /something/, causing no data to ever be read
from the socket.  (I do not understand the exact cause.)

As part of this change, also refactor how the remote read is
handled.  The choice of which channel to read and handling of
blocking channels is now abstracted behind the remoteRead() method,
which subsumes boundRead().

This commit also addresses a subtle bug.  If the readBuffer contains
more data than the capacity of the j_buffer to which it is written,
and if the dst buffer(s) get filled, then JSSSocketChannel.read()
can terminate with leftover data in readBuffer.  Upon the next
invocation of read(), readBuffer.clear() is called, discarding those
data.  This commit modifies read() to ensure that leftover data in
readBuffer are compacted and preserved.

- - - - -
c2b1d83f by Fraser Tweedale at 2020-10-28T09:56:50-04:00
PR.Read: return data when end of stream reached

Commit 424d55639c51bca18110dcff51fb5df2e2e35a41 introduced a
workaround in PR.Read for a bug in NSS' PR_Read that occurs on some
platforms.  The bug can cause PR_Read to return a smaller amount
than requested, even when more data is available.  The workaround is
to loop until we have either read the requested amount, or we
encounter PR_WOULD_BLOCK_ERROR.

Unfortunatley there is a bug in the workaround: the end of stream
case was not considered.  In this case, the first PR_Read reads less
than the requested amount, and we loop.  The next PR_Read returns 0,
but the "not an error" condition

    PR_GetError() == PR_WOULD_BLOCK_ERROR && read_amount > 0

does not admit the end of stream case (PR_GetError() == 0).  As a
consequence, PR.Read returns an empty byte[] and the data from the
final read before end of stream are lost.

To resolve this issue, break the loop when PR_Read returns <= 0 but
PR_GetError() returns 0.

- - - - -
65c27519 by Fraser Tweedale at 2020-10-28T09:56:50-04:00
JSSSocketChannel.read: record when input is closed

When reading the socket channel, no special action is taken when the
SSLEngine.unwrap() returns an SSLEngineResult with status CLOSED.
As a consequence, JSSSocketChannel.read() never returns -1, even
after the sender has closed their send end of the socket and the TLS
close_notify alert has been processed.  Programs that rely on the
read() returning -1 to indicate end of data will loop forever.

To resolve, call shutdownInput() when unwrap() indicates that the
read side of the socket is closed.  This idempotent action causes
subsequent invocations of read() to return -1, as required by the
SocketChannel contract.

- - - - -
9502efb6 by Alexander Scheel at 2020-10-28T15:46:06-04:00
Release JSS v4.8.0

This version of JSS has a few minor improvements over v4.7.x series:

 - Porting from Apache Commons Lang 2 to 3
 - A few memory fixes
 - Two contributions from Fraser Tweedale:
   - Fix missing OIDMap mappings for X.509 extensions
   - JSSSocketChannel.read(): deliver all data from buffer fd

Thanks to everyone who contributed to this release!

Signed-off-by: Alexander Scheel <ascheel at redhat.com>

- - - - -
1b24a4e7 by Timo Aaltonen at 2020-10-31T19:03:57+02:00
Merge commit 'a715520a0dc7d4a' into m

- - - - -
cc45229d by Timo Aaltonen at 2020-10-31T19:04:02+02:00
Merge branch 'master' into m

- - - - -
7b800622 by Timo Aaltonen at 2020-10-31T19:04:39+02:00
bump the version

- - - - -
74ec5d76 by Timo Aaltonen at 2020-10-31T19:10:04+02:00
control: Build using libcommons-lang3-java.

- - - - -
bc4641ad by Timo Aaltonen at 2020-10-31T19:16:39+02:00
releasing package jss version 4.8.0-1

- - - - -


30 changed files:

- .classpath
- .github/workflows/required.yml
- README.md
- cmake/JSSConfig.cmake
- debian/changelog
- debian/control
- docs/contributing.md
- + docs/usage/cryptomanager.md
- jss.spec
- org/mozilla/jss/CryptoManager.java
- org/mozilla/jss/JSSLoader.java
- org/mozilla/jss/crypto/KBKDF.c
- org/mozilla/jss/netscape/security/pkcs/PKCS12Util.java
- org/mozilla/jss/netscape/security/util/Cert.java
- org/mozilla/jss/netscape/security/x509/OIDMap.java
- org/mozilla/jss/netscape/security/x509/RevocationReasonAdapter.java
- org/mozilla/jss/nss/PR.c
- org/mozilla/jss/pkcs11/PK11PrivKey.c
- org/mozilla/jss/pkcs11/PK11PubKey.c
- org/mozilla/jss/pkcs11/PK11Token.c
- org/mozilla/jss/provider/java/security/JSSKeyStoreSpi.java
- org/mozilla/jss/provider/javax/crypto/JSSTrustManager.java
- org/mozilla/jss/ssl/callbacks.c
- org/mozilla/jss/ssl/javax/JSSEngine.java
- org/mozilla/jss/ssl/javax/JSSEngineReferenceImpl.java
- org/mozilla/jss/ssl/javax/JSSSocketChannel.java
- org/mozilla/jss/tests/TestSSLEngine.java
- org/mozilla/jss/tests/UTF8ConverterTest.java
- tools/Dockerfiles/debian_jdk11
- tools/Dockerfiles/fedora_27


The diff was not included because it is too large.


View it on GitLab: https://salsa.debian.org/freeipa-team/jss/-/compare/687fd3ab4f0150d992955280c7d863c7b7770054...bc4641ad721efe0dd6fec2c12f43bc801fbd7087

-- 
View it on GitLab: https://salsa.debian.org/freeipa-team/jss/-/compare/687fd3ab4f0150d992955280c7d863c7b7770054...bc4641ad721efe0dd6fec2c12f43bc801fbd7087
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeipa-devel/attachments/20201031/525d88ce/attachment-0001.html>

More information about the Pkg-freeipa-devel mailing list