Find TLS key exchange (named groups) configuration
ProprietaryInventories every place a codebase decides which TLS key-exchange groups it offers, and classifies each by whether an ML-KEM hybrid group — the thing JEP 527 and BouncyCastle 1.81 add — is among them. Covers SSLParameters.setNamedGroups and BCSSLParameters.setNamedGroups, the jdk.tls.namedGroups system property set in code or embedded as a -D flag in checked-in YAML and .properties files, getSupportedGroups overrides on BouncyCastle AbstractTlsClient subclasses, BCJSSE provider registration, and jdk.tls.disabledAlgorithms values that disable a hybrid group. When the repository configures named groups nowhere, each TLS-using file gets one A row: that code is post-quantum ready as soon as it runs on JDK 27 or BouncyCastle 1.81, with no source change. -D flags in shell scripts, Dockerfiles and orchestration manifests outside the repository are invisible, so an absent row is not proof that no group pin exists.
io.Optional
Emit one A row per TLS-using source file when the repository configures named groups nowhere at all, anchored at the first TLS entry-point call in the file. This is the row that says "this code becomes post-quantum ready by upgrading the runtime, with no source change", which for most repositories is the whole answer. Set to false for a call-site-only inventory. Default true.
Also flag ad-hoc .properties and YAML keys whose name looks like a named-groups setting, e.g. tls.named-groups. Off by default: neither the JDK nor Spring Boot has a first-class named-groups configuration key, so any such key is an application's own invention and matching on the name alone produces false positives. The -Djdk.tls.namedGroups= flag embedded in a JVM-options value is matched either way.
mod run .Install it once from Recipe actions, then run it on every repository under the current directory. New to the Moderne CLI? Set it up.