live wire
▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM
upstreambeat.ai
releaseJAVA

Quarkus 3.39 adds post-quantum TLS controls before its next LTS

The release adds configurable quantum-resistant key exchange while reverting reflection-free Jackson serializers to opt-in.

Quarkus release shows new TLS controls and a reverted serializer default.
AI-generated illustration
By The News Desk· Aug 27, 2026

Quarkus 3.39 is out with controls for post-quantum cryptography in its TLS registry, while the project prepares the code line that will become its next long-term-support release.

The Quarkus release announcement says version 3.39 will form the base for Quarkus 3.40 LTS. The project is encouraging users to migrate now so remaining problems can be found before that LTS ships. It also describes 3.39 as lighter than usual because more feature and upgrade work has shifted to Quarkus 4.

What changed

The main addition wires the Vert.x post-quantum cryptography API through Quarkus’s HTTP server, HTTP client, REST client and mailer. Applications can now configure ordered TLS key-exchange groups, including algorithms such as ML-KEM.

A new enforcement setting gives operators three choices: require post-quantum cryptography, prefer it while permitting a fallback to classical cryptography, or leave it unenforced. Another setting can force the OpenSSL or JDK SSL engine when an algorithm is available in only one implementation.

This is infrastructure rather than an automatic security switch. Teams need to select key-exchange groups and an enforcement policy appropriate to their clients and interoperability requirements. The new options nevertheless put quantum-resistant TLS negotiation on the normal Quarkus configuration path instead of requiring application-specific wiring.

A default is rolled back

Quarkus 3.39 also reverses an earlier default: reflection-free Jackson serializers return to opt-in. The project says unresolved issues made the feature unsuitable as a default for the coming LTS. Applications that depend on it can explicitly re-enable quarkus.rest.jackson.optimization.enable-reflection-free-serializers.

That rollback is the practical migration detail to check first. Teams testing 3.39 should verify JSON serialization behavior as well as TLS negotiation before treating the release as representative of the eventual LTS.

What teams should do

The project recommends updating with the latest Quarkus CLI and running quarkus update; it says the command can move applications from any Quarkus version, including 2.x, to 3.39. A separate migration guide documents required application adjustments.

The platform update also brings Camel Quarkus 3.39.0, Quarkus CXF 3.39.1, Quarkus Flow 1.0.0 and Quarkus LangChain4j 1.13.0. For platform teams planning the next LTS, 3.39 is best read as the test window: validate serialization assumptions, exercise the new TLS policy modes and report regressions before the 3.40 branch hardens.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk