update prod #4609
Merged
update prod #4609
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ayoho
reviewed
Nov 17, 2025
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| === Limitations of the Beta release: | ||
| ==== HTTP | ||
| * HTTP requests with content length greater than the maximum integer value fails due to internal limitations on request size with Netty. | ||
| * When the http option `maxKeepAliveRequests` has no limit, HTTP 1.1 limits pipelined requests to 50. |
Member
There was a problem hiding this comment.
Suggested change
| * When the http option `maxKeepAliveRequests` has no limit, HTTP 1.1 limits pipelined requests to 50. | |
| * When the HTTP option `maxKeepAliveRequests` has no limit, HTTP 1.1 limits pipelined requests to 50. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| ==== HTTP | ||
| * HTTP requests with content length greater than the maximum integer value fails due to internal limitations on request size with Netty. | ||
| * When the http option `maxKeepAliveRequests` has no limit, HTTP 1.1 limits pipelined requests to 50. | ||
| * Http option `resetFramesWindow` is reduced from millisecond to second precision due to limitations in the Netty library. |
Member
There was a problem hiding this comment.
Suggested change
| * Http option `resetFramesWindow` is reduced from millisecond to second precision due to limitations in the Netty library. | |
| * HTTP option `resetFramesWindow` is reduced from millisecond to second precision due to limitations in the Netty library. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| * Due to internal limitations of the Netty library, the http option `MessageSizeLimit` is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections. | ||
| * Due to internal differences with Netty, the http option `ThrowIOEForInboundConnections` could behave differently from the Channel Framework implementation. | ||
| * Due to internal limitations of Netty, `acceptThread` and `waitToAccept` TCP options are currently not implemented and are ignored for the current Beta if set. | ||
| * As of the moment, clear text upgrade requests for HTTP 2.0 with request data is rejected with a 'Request Entity Too Large' status code. A fix is in progress. |
Member
There was a problem hiding this comment.
Suggested change
| * As of the moment, clear text upgrade requests for HTTP 2.0 with request data is rejected with a 'Request Entity Too Large' status code. A fix is in progress. | |
| * Cleartext upgrade requests for HTTP 2.0 with request data are rejected with a 'Request Entity Too Large' status code. A fix is in progress. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| [#aes256] | ||
| == Bring Your Own AES-256 Key | ||
|
|
||
| The *Bring Your Own AES-256 Key* feature allows you to provide a *Base64-encoded 256-bit AES key* for password encryption in Liberty. |
Member
There was a problem hiding this comment.
Suggested change
| The *Bring Your Own AES-256 Key* feature allows you to provide a *Base64-encoded 256-bit AES key* for password encryption in Liberty. | |
| Liberty now allows you to provide a Base64-encoded 256-bit AES key for password encryption. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| === What’s New? | ||
| Previously, Liberty supported the `wlp.password.encryption.key` property, which accepted a password and derived an AES key through a computationally intensive process. This derivation involved repeated hashing with a salt over many iterations, which added overhead during server startup. | ||
|
|
||
| With *Bring Your Own AES-256 Key*, you can now supply a pre-generated AES key directly. This eliminates the derivation step, resulting in *faster startup times and improved runtime performance* when encrypting and decrypting passwords. |
Member
There was a problem hiding this comment.
Suggested change
| With *Bring Your Own AES-256 Key*, you can now supply a pre-generated AES key directly. This eliminates the derivation step, resulting in *faster startup times and improved runtime performance* when encrypting and decrypting passwords. | |
| Now you can now supply a pre-generated AES key directly. This eliminates the derivation step, resulting in faster startup times and improved runtime performance when encrypting and decrypting passwords. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| With *Bring Your Own AES-256 Key*, you can now supply a pre-generated AES key directly. This eliminates the derivation step, resulting in *faster startup times and improved runtime performance* when encrypting and decrypting passwords. | ||
|
|
||
| === Why It Matters | ||
| This feature not only improves performance but also prepares for *migration from traditional WebSphere (tWAS)*. The encoded password format remains the same, and future migration tools will allow you to export keys from tWAS for use in Liberty. |
Member
There was a problem hiding this comment.
Suggested change
| This feature not only improves performance but also prepares for *migration from traditional WebSphere (tWAS)*. The encoded password format remains the same, and future migration tools will allow you to export keys from tWAS for use in Liberty. | |
| This feature not only improves performance but also prepares for migration from traditional WebSphere. The encoded password format remains the same, and future migration tools will allow you to export keys from traditional WebSphere for use in Liberty. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| ```bash | ||
| ./securityUtility encode --encoding=aes --base64Key=<your_base64_key> <password> | ||
| ``` | ||
| * Specify an XML or properties file containing `wlp.aes.encryption.key` or `wlp.password.encryption.key`. *Note:* The aesKeyFile parameter now allows users to encode with either of the aes properties: |
Contributor
Author
There was a problem hiding this comment.
I confimed with the author and changes them, Thanks!
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
|
|
||
| *Performance Tip:* For best results, re-encode all passwords using the new key. Mixed usage of old and new formats is supported for backward compatibility, but full migration ensures optimal performance. | ||
|
|
||
| Other command line tasks have been updated to accept base64 keys and aes configuration files in a similar fashion: |
Member
There was a problem hiding this comment.
Suggested change
| Other command line tasks have been updated to accept base64 keys and aes configuration files in a similar fashion: | |
| Other command line tasks have been updated to accept Base64 keys and AES configuration files in a similar fashion: |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| * HTTP requests with content length greater than the maximum integer value fails due to internal limitations on request size with Netty. | ||
| * When the http option `maxKeepAliveRequests` has no limit, HTTP 1.1 limits pipelined requests to 50. | ||
| * Http option `resetFramesWindow` is reduced from millisecond to second precision due to limitations in the Netty library. | ||
| * Due to internal limitations of the Netty library, the http option `MessageSizeLimit` is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections. |
Member
There was a problem hiding this comment.
Suggested change
| * Due to internal limitations of the Netty library, the http option `MessageSizeLimit` is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections. | |
| * Due to internal limitations of the Netty library, the HTTP option `MessageSizeLimit` is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections. |
posts/2025-11-18-25.0.0.12-beta.adoc
Outdated
| * When the http option `maxKeepAliveRequests` has no limit, HTTP 1.1 limits pipelined requests to 50. | ||
| * Http option `resetFramesWindow` is reduced from millisecond to second precision due to limitations in the Netty library. | ||
| * Due to internal limitations of the Netty library, the http option `MessageSizeLimit` is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections. | ||
| * Due to internal differences with Netty, the http option `ThrowIOEForInboundConnections` could behave differently from the Channel Framework implementation. |
Member
There was a problem hiding this comment.
Suggested change
| * Due to internal differences with Netty, the http option `ThrowIOEForInboundConnections` could behave differently from the Channel Framework implementation. | |
| * Due to internal differences with Netty, the HTTP option `ThrowIOEForInboundConnections` could behave differently from the Channel Framework implementation. |
Updates to 25.0.0.12-beta blog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Link to blog: https://blogs-staging-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/blog/2025/11/18/25.0.0.12-beta.html