Source code
package io.netty.handler.ssl;
import io.netty.internal.tcnative.SSLPrivateKeyMethod;
import io.netty.util.internal.UnstableApi;
import javax.net.ssl.SSLEngine;
/**
* Allow to customize private key signing / decrypting (when using RSA). Only supported when using BoringSSL atm.
*/
@UnstableApi
public interface OpenSslPrivateKeyMethod {
int SSL_SIGN_RSA_PKCS1_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA1;
int SSL_SIGN_RSA_PKCS1_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA256;
int SSL_SIGN_RSA_PKCS1_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA384;
int SSL_SIGN_RSA_PKCS1_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA512;
int SSL_SIGN_ECDSA_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SHA1;
int SSL_SIGN_ECDSA_SECP256R1_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP256R1_SHA256;
int SSL_SIGN_ECDSA_SECP384R1_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP384R1_SHA384;
int SSL_SIGN_ECDSA_SECP521R1_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP521R1_SHA512;
int SSL_SIGN_RSA_PSS_RSAE_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA256;
int SSL_SIGN_RSA_PSS_RSAE_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA384;
int SSL_SIGN_RSA_PSS_RSAE_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA512;
int SSL_SIGN_ED25519 = SSLPrivateKeyMethod.SSL_SIGN_ED25519;
int SSL_SIGN_RSA_PKCS1_MD5_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_MD5_SHA1;
/**
* Signs the input with the given key and returns the signed bytes.
*
* @param engine the {@link SSLEngine}
* @param signatureAlgorithm the algorithm to use for signing
* @param input the digest itself
* @return the signed data (must not be {@code null})
* @throws Exception thrown if an error is encountered during the signing
*/
byte[] sig(SSLEngine eng, int signature, byte[] inp) throws Exception;
/**
* Decrypts the input with the given key and returns the decrypted bytes.
*
* @param engine the {@link SSLEngine}
* @param input the input which should be decrypted
* @return the decrypted data (must not be {@code null})
* @throws Exception thrown if an error is encountered during the decrypting
*/
byte[] dec(SSLEngine eng2, byte[] inp2) throws Exception;
}
Run 1
The code is highly readable. It is well-structured as a concise interface with clear separation of constants and method declarations. Nesting is minimal, which aligns with interface design. Naming of constants and methods is explicit, making the intent unambiguous. The code is appropriately concise for its purpose, with one action or declaration per line. Javadocs provide clear context for the methods and parameters, enhancing the reading flow. The only slight drawbacks are shortened parameter names (e.g., 'sig', 'dec', 'eng', 'inp') and minor Javadoc inconsistency (parameter named 'engine' vs 'eng'), which slightly reduce formal clarity.
Run 2
The code is well-structured and clear, with good documentation. The interface has a logical organization of constants and methods, flat structure, and clear intent. However, the method signatures use abbreviated parameter names that reduce readability, the methods themselves have somewhat generic names like 'sig' and 'dec', and the constants section is quite long without grouping, which could benefit from better organization.
Run 3
The code is generally readable and well-structured as an interface definition. It logically groups related constants and documents methods with Javadoc. However, readability is hindered by abbreviated method and parameter names (`sig`, `dec`, `eng`, `inp`), which are ambiguous despite Javadoc explanations. The long list of constants is flat and repetitive, though unavoidable for such mappings. The constant declarations are concise and reference native constants, but the repetition adds length. The interface is flat with no nesting, and each method declaration is on one line, aiding quick scanning. The Javadoc provides clear intent and parameter descriptions, improving understanding. Some inconsistency exists between parameter names in Javadoc (`engine`, `input`) and signatures (`eng`, `inp`), creating minor confusion. Overall, the structure and clarity are good, but naming choices and repetition reduce readability.
Run 1
Code Structure: Logically organized into imports, algorithm constants, and two documented methods; grouping constants by algorithm would improve scanning. Nesting: Flat interface with no nested control flow. Clarity of intent: Constants and documentation explain the purpose, but abbreviated method names (sig, dec) and parameters (eng, inp, eng2, inp2) obscure meaning. Javadoc parameter names do not match the declarations, reducing clarity and documentation reliability. Code length: Concise for the interface's scope; repetitive constants are justified. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural top-to-bottom progression, slightly weakened by dense constant declarations, minimal spacing around imports, and inconsistent parameter naming.
Run 2
Code Structure: The interface is logically organized into constants and two documented operations, though spacing and constant grouping could improve scanning. Nesting: Flat declarations with no nested control flow make it easy to follow. Clarity of intent: Descriptive constants and documentation explain the purpose, but abbreviated method and parameter names (sig, dec, eng, inp, eng2, inp2) obscure meaning. Javadoc parameter names do not match the actual signatures, creating confusion. Code length: Appropriately concise for an interface; the repeated constant mappings are straightforward rather than unnecessary. Action granularity: Each declaration occupies its own line, with no bundled actions. Reading flow: Constants followed by signing and decryption methods provide a natural progression, weakened by inconsistent naming and mismatched documentation.
Run 3
Code Structure: Logically organized into imports, algorithm constants, and two documented interface methods, though spacing and constant grouping could improve scanning. Nesting: Flat, with no nested control flow. Clarity of intent: Constants and documentation explain the purpose, but abbreviated method names (sig, dec) and parameters (eng, inp, eng2, inp2) reduce clarity. Javadoc parameter names do not match the declarations, creating confusion. Code length: Appropriately concise; the repetitive constants provide useful API definitions rather than unnecessary logic. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Generally natural, moving from supported algorithms to operations, but inconsistent naming and inaccurate parameter documentation interrupt comprehension.