Build #2,999

Plan branch:
Verifies the integrety of the projects, as builds are executed immediately after a code change was detected. This plan provides no artifiacts (use a nightly build instead).

Build: #2999 was successful

Job: Build was successful

Stages & jobs

  1. Default Stage

  2. Continuous Integration

Code commits

Openfire (master)

  • Guus der Kinderen

    Guus der Kinderen 34fe107014cab945dadb7c5a5435f3df140e4055

    OF-3259: Deprecate legacy certificate validity verification properties and unify configuration
    In OF-946 refactor, connection configuration introduced per-type prefixed properties. However, not all usages of the legacy properties were migrated. As a result, some functionality still depends on the old properties while others use the new ones (sometimes even within related features) leading to inconsistent and incompatible behavior (e.g., server-to-server uses new properties, while Dialback relies on legacy ones).

    This commit deprecates the legacy `xmpp.server.certificate.verify.validity` and `xmpp.client.certificate.verify.validity` properties in favor of `ConnectionListener#verifyCertificateValidity`.

    Changes:
    - Add fallback: the new configuration uses the legacy property if it is explicitly set.
    - Migrate all remaining usages from the legacy property to the new configuration.

    This ensures consistent behavior across all connection types and prevents configuration mismatches.

    • xmppserver/src/main/java/org/jivesoftware/openfire/net/ClientTrustManager.java (version 34fe107014cab945dadb7c5a5435f3df140e4055)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/ConnectionSettings.java (version 34fe107014cab945dadb7c5a5435f3df140e4055)
    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/ConnectionListener.java (version 34fe107014cab945dadb7c5a5435f3df140e4055)
  • Scott Milne <smilne1282@gmail.com>

    Scott Milne <smilne1282@gmail.com> 9045deaf7e7e258bcfba4e07fe8091f48ddc0c22

    Fix S2S dialback not offered in post-TLS features when self-signed certs accepted
    ServerDialback.isEnabledForSelfSigned() reads the legacy property
    xmpp.server.certificate.accept-selfsigned (TLS_ACCEPT_SELFSIGNED_CERTS),
    but ConnectionListener.setAcceptSelfSignedCertificates() — which backs the
    Admin Console UI checkbox — writes to the per-connection-type prefixed
    property xmpp.socket.ssl.certificate.accept-selfsigned. These diverged when
    per-type prefixed properties were introduced but the readers in ServerDialback
    were not updated.

    The consequence is that after a successful TLS handshake with a self-signed
    peer certificate, LocalIncomingServerSession.getAvailableStreamFeatures() calls
    isEnabledForSelfSigned(), gets false, and omits <db:dialback> from the post-TLS
    <stream:features>. The connecting server then finds no usable authentication
    mechanism and closes the connection. This causes all encrypted S2S connections
    to fail silently when the only option is dialback, even if the operator has
    enabled self-signed certificate acceptance via the UI.

    Fix: check both property names in isEnabledForSelfSigned(), preserving full
    backwards compatibility with installations that have the legacy property set.

    Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

    • xmppserver/src/main/java/org/jivesoftware/openfire/server/ServerDialback.java (version 9045deaf7e7e258bcfba4e07fe8091f48ddc0c22)
  • Guus der Kinderen

    Guus der Kinderen 08a89cbcbae2a95a5d0ad7675517f22fb0d645bf

    Mark unused xmpp.server.certificate and xmpp.client.certificate properties for removal
    `org.jivesoftware.openfire.net.ClientTrustManager` has been replaced by `org.jivesoftware.openfire.keystore.OpenfireX509TrustManager` at least a decade ago. It is unlikely that it's still being used.

    These properties are used _exclusively_ by this old implementation. As that implementation isn't in use any more, these properties are effectively unused.

    - `xmpp.client.certificate.verify`
    - `xmpp.client.certificate.crl`
    - `xmpp.client.certificate.verify.chain`
    - `xmpp.client.certificate.verify.root`

    This commit explicitly marks the `ClientTrustManager` as being deprecated, for removal in Openfire 5.2.0. I don't think there's much value in retaining the properties, as their functionality seems questionably specific. Apparently, it hasn't been missed in the last decade.

    There properties above are specific to client connectivity.

    For server connectivity, things are slightly different. There also exists `org.jivesoftware.openfire.net.ServerTrustManager` which also goes unused. It is unlikely that it's still begin used. This implementation, unlike its client-counterpart, does not (directly) use similar properties.

    This commit explicitly marks the `ServerTrustManager` as being deprecated, for removal in Openfire 5.2.0.

    The properties mentioned above have server-equivalents:
    - `xmpp.server.certificate.verify`
    - `xmpp.server.certificate.verify.chain`
    - `xmpp.server.certificate.verify.root`

    (`xmpp.server.certificate.crl` is not defined)

     Unlike the client properties, these server properties are used in other bits of code.

    `xmpp.server.certificate.verify` (as constant `org.jivesoftware.openfire.session.ConnectionSettings.Server#TLS_CERTIFICATE_VERIFY`)
    - appears to be used in `org.jivesoftware.openfire.net.SASLAuthentication` to assert if, for every server-to-server SASL authentication mechanism applied to incoming server-to-server connections, the peer's certificates should be validated. There's just one SASL mechanism for incoming server-to-server connections, which is EXTERNAL. Its implementation seems to unconditionally verify certificates in `org.jivesoftware.openfire.sasl.ExternalServerSaslServer` - the SASL mechanisms that we offer to server peers (in `org.jivesoftware.openfire.net.SASLAuthentication`) only offers EXTERNAL when the peer's certificates are unconditionally validated. In this path, the property doesn't seem to be useful.
    - is used in `org.jivesoftware.openfire.net.ServerStanzaHandler` to populate a variable that is not used. In this path, the property does not seem to be useful either.
    - is used in `org.jivesoftware.openfire.net.TLSStreamHandler` to configure a TLS Engine, specifically to check if a peer's certificate is wanted, or needed. `TLSStreamHandler` itself is used by `org.jivesoftware.openfire.server.ServerDialback` and `org.jivesoftware.openfire.net.SocketConnection` (which is documented to be used only for Server Dialback). Server Dialback is a mechanism used when SASL EXTERNAL (which is based on TLS certifiate validation) is unavailable. It seems unlikely that low-level configuration of TLS certificates is required (or even desired) for Server Dialback.

    In all, `xmpp.server.certificate.verify` seems to be largely unused.

    `xmpp.server.certificate.verify.chain` (as constant `org.jivesoftware.openfire.session.ConnectionSettings.Server#TLS_CERTIFICATE_CHAIN_VERIFY`)
    - is used in `org.jivesoftware.openfire.net.ServerStanzaHandler` to populate a variable that is not used. In this path, the property does not seem to be useful.
    - is used in `org.jivesoftware.openfire.net.TLSStreamHandler` to configure a TLS Engine, specifically to check if a peer's certificate is wanted, or needed. TLSStreamHandler itself is used by `org.jivesoftware.openfire.server.ServerDialback` and `org.jivesoftware.openfire.net.SocketConnection` (which is documented to be used only for Server Dialback). Server Dialback is a mechanism used when SASL EXTERNAL (which is based on TLS certifiate validation) is unavailable. It seems unlikely that low-level configuration of TLS certificates is required (or even desired) for Server Dialback.

    In all, `xmpp.server.certificate.verify.chain` seems to be largely unused.

    `xmpp.server.certificate.verify.root` (as constant `org.jivesoftware.openfire.session.ConnectionSettings.Server#TLS_CERTIFICATE_ROOT_VERIFY`)
    - Only defined as a constant, but the constant is not used.

    I believe all of the above is reason to phase out all of these properties:
    - `xmpp.client.certificate.verify`
    - `xmpp.client.certificate.crl`
    - `xmpp.client.certificate.verify.chain`
    - `xmpp.client.certificate.verify.root`
    - `xmpp.server.certificate.verify`
    - `xmpp.server.certificate.verify.chain`
    - `xmpp.server.certificate.verify.root`

    Unlike the properties `xmpp.server.certificate.verify.validity`, `xmpp.client.certificate.verify.validity`, `xmpp.server.certificate.accept-selfsigned` and xmpp.client.certificate.accept-selfsigned` that have been deprecated in earlier commits, but have been replaced by `ConnectionListener` functionality, I see little value in introducing new functionality in `ConnectionListener` to match the properties above.

    In this commit, I have marked the constants that define the properties above as being deprecated, for removal in Openfire 5.2.0. Properties for which no constant is defined are used in code that is already marked for removal, so they'll disappear automatically.

    • xmppserver/src/main/java/org/jivesoftware/openfire/net/ClientTrustManager.java (version 08a89cbcbae2a95a5d0ad7675517f22fb0d645bf)
    • xmppserver/src/main/java/org/jivesoftware/openfire/net/ServerTrustManager.java (version 08a89cbcbae2a95a5d0ad7675517f22fb0d645bf)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/ConnectionSettings.java (version 08a89cbcbae2a95a5d0ad7675517f22fb0d645bf)
  • Guus der Kinderen

    Guus der Kinderen 08655d86eddd06c53610dbf5a65b66c91683cf89

    OF-3259: Deprecate legacy self-signed certificate properties and unify configuration
    In OF-946 refactor, connection configuration introduced per-type prefixed properties. However, not all usages of the legacy properties were migrated. As a result, some functionality still depends on the old properties while others use the new ones (sometimes even within related features) leading to inconsistent and incompatible behavior (e.g., server-to-server uses new properties, while Dialback relies on legacy ones).

    This commit deprecates the legacy `xmpp.server.certificate.accept-selfsigned` and xmpp.client.certificate.accept-selfsigned` properties in favor of `ConnectionListener#acceptSelfSignedCertificates`.

    Changes:
    - Add fallback: the new configuration uses the legacy property if it is explicitly set.
    - Migrate all remaining usages from the legacy property to the new configuration.

    This ensures consistent behavior across all connection types and prevents configuration mismatches.

    • xmppserver/src/main/java/org/jivesoftware/openfire/net/ClientTrustManager.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
    • xmppserver/src/main/java/org/jivesoftware/openfire/net/ServerStanzaHandler.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
    • xmppserver/src/main/java/org/jivesoftware/openfire/net/ServerTrustManager.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
    • xmppserver/src/main/java/org/jivesoftware/openfire/net/TLSStreamHandler.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
    • xmppserver/src/main/java/org/jivesoftware/openfire/server/ServerDialback.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/ConnectionSettings.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/ConnectionListener.java (version 08655d86eddd06c53610dbf5a65b66c91683cf89)
  • Guus der Kinderen

    Guus der Kinderen 9059f5cbd6658dc0a2323be3cd4f6752a28b91dc

    OF-3272 CSI: flush delayed queue outside lock and serialize activation flush
    Refactor CSI activation flushing to avoid holding the CsiManager monitor during delivery I/O and preserve stanza ordering across activation.

    • xmppserver/src/main/java/org/jivesoftware/openfire/csi/CsiManager.java (version 9059f5cbd6658dc0a2323be3cd4f6752a28b91dc)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalClientSession.java (version 9059f5cbd6658dc0a2323be3cd4f6752a28b91dc)
    • xmppserver/src/test/java/org/jivesoftware/openfire/csi/CsiManagerTest.java (version 9059f5cbd6658dc0a2323be3cd4f6752a28b91dc)
  • Guus der Kinderen

    Guus der Kinderen 3332aec459a99ba5713079bac3b8d0ffaf83d72d

    (code review) remove redundant check for empty collection

    • xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalClientSession.java (version 3332aec459a99ba5713079bac3b8d0ffaf83d72d)
  • Guus der Kinderen

    Guus der Kinderen 75b1d41c24bbf198cafea94d946d427106b31922

    OF-3272: Fix concurrency (and off-by-one) issue in CSI
    The implementation was partially synchronized, but lacked synchronization on activate/deactivate. By marking both methods as synchronized, there no longer is a data race.

    In activate, the rescheduling of queued stanzas was previously performed outside of a lock, although its execution (in `queueOrPush`) was fully synchronized. Because of that, I don't expect this commit to introduce significant more (possibly problematic, remember Stream Management?) locking.

    This commit also addresses a minor off-by-one error when checking the queue capacity.

    • xmppserver/src/main/java/org/jivesoftware/openfire/csi/CsiManager.java (version 75b1d41c24bbf198cafea94d946d427106b31922)
  • Guus der Kinderen

    Guus der Kinderen 238f9af1465e5af631c0d4066a4f3560576048f4

    OF-3272: Increase unit test coverage for CsiManager

    • xmppserver/src/test/java/org/jivesoftware/openfire/csi/CsiManagerTest.java (version 238f9af1465e5af631c0d4066a4f3560576048f4)
  • Dave Cridland <dave@cridland.net>

    Dave Cridland <dave@cridland.net> d92d48ac2ed3b69391b4c62ddf98ff9ad5952c5b

    fix: synchronize CsiManager.activate() and flush full queue atomically
    activate() was not synchronized, causing a race with queueOrPush() on
    the shared queue field. It also used an indirect flush (pollLast + re-
    deliver) that could lose stanzas queued between pollLast and the re-
    entry into queueOrPush.

    Fix: drain the entire queue atomically under the lock, set active=true,
    then deliver all stanzas outside the lock so I/O does not block other
    threads from queuing new stanzas.

    Co-authored-by: Junie <junie@jetbrains.com>

    • xmppserver/src/main/java/org/jivesoftware/openfire/csi/CsiManager.java (version d92d48ac2ed3b69391b4c62ddf98ff9ad5952c5b)
  • Guus der Kinderen

    Guus der Kinderen f9cd191b6b84d7428fd3d3344336ffee8d3257a4

    OF-3277: Introduce helper method to determine database 'limit' keyword
    The SQL LIMIT clause is not portable across the databases Openfire supports. SQL Server, for example, uses `SELECT TOP`.

    Up until now, code had to interrogate the type of database to find out what variant to be used. In this commit, this information is exposed as metadata.

    Small changes have been applid to the pubsub persistence implementation. It is expected that the Monitoring plugin (and others) benefit from this, too.

    • xmppserver/src/main/java/org/jivesoftware/database/DbConnectionManager.java (version f9cd191b6b84d7428fd3d3344336ffee8d3257a4)
    • xmppserver/src/main/java/org/jivesoftware/openfire/pubsub/DefaultPubSubPersistenceProvider.java (version f9cd191b6b84d7428fd3d3344336ffee8d3257a4)
    • xmppserver/src/test/java/org/jivesoftware/database/DbConnectionManagerTest.java (version f9cd191b6b84d7428fd3d3344336ffee8d3257a4)