String() — netty Function Reference

Architecture documentation for the String() function in SslContext.java from the netty codebase.

Function java Buffer Allocators

Entity Profile

Buffer→ Allocators→ String() — netty Function Reference

Dependency Diagram

graph TD
  b43c377a_a626_ba6d_d74e_d080097e22be["String()"]
  ec56e535_0508_8846_8172_a704185d370e["SslContext"]
  b43c377a_a626_ba6d_d74e_d080097e22be -->|defined in| ec56e535_0508_8846_8172_a704185d370e
  style b43c377a_a626_ba6d_d74e_d080097e22be fill:#6366f1,stroke:#818cf8,color:#fff

Relationship Graph

Source Code

handler/src/main/java/io/netty/handler/ssl/SslContext.java lines 1123–1142

    private static String getPBEAlgorithm(EncryptedPrivateKeyInfo encryptedPrivateKeyInfo) {
        AlgorithmParameters parameters = encryptedPrivateKeyInfo.getAlgParameters();
        String algName = encryptedPrivateKeyInfo.getAlgName();
        // Java 8 ~ 16 returns OID_PKCS5_PBES2
        // Java 17+ returns PBES2
        if (parameters != null && (OID_PKCS5_PBES2.equals(algName) || PBES2.equals(algName))) {
            /*
             * This should be "PBEWith<prf>And<encryption>".
             * Relying on the toString() implementation is potentially
             * fragile but acceptable in this case since the JRE depends on
             * the toString() implementation as well.
             * In the future, if necessary, we can parse the value of
             * parameters.getEncoded() but the associated complexity and
             * unlikeliness of the JRE implementation changing means that
             * Tomcat will use to toString() approach for now.
             */
            return parameters.toString();
        }
        return encryptedPrivateKeyInfo.getAlgName();
    }