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[] emit(SSLEngine status, int pendingRequest, byte[] group) 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[] deliver(SSLEngine config, byte[] count) throws Exception;
}
Run 1
The code is well-structured with clear imports, a concise Javadoc, and a logical grouping of constants. Nesting is minimal, and the interface methods are clearly separated with descriptive documentation. However, readability is hindered by poor parameter naming in the method declarations: 'emit' uses 'status', 'pendingRequest', and 'group' which do not reflect their documented purposes (SSLEngine, signatureAlgorithm, input). Similarly, 'deliver' uses 'config' and 'count' instead of 'engine' and 'input'. These ambiguous names reduce clarity of intent. The constant declarations are repetitive but acceptable for this pattern. Overall, the code is easy to follow but would benefit from consistent, meaningful parameter names.
Run 2
The code structure is logical and clean, with a well-defined interface and helpful Javadoc comments. It's mostly flat with no complex nesting. However, readability is hurt by misleading parameter names: 'status', 'pendingRequest', 'group', 'config', and 'count' do not clearly indicate their purpose, obscuring intent. The code is concise and has good action granularity, but the reading flow is interrupted by these ambiguous names. The long list of constants is acceptable as it maps clearly to SSL algorithms.
Run 3
The code is structurally simple but suffers from poor readability due to naming and formatting choices. The interface is flat and logically organized, with constants grouped together and methods separated by Javadoc. However, the intent is obscured by misleading parameter names like 'status', 'pendingRequest', 'group', 'config', and 'count', which do not reflect their actual roles (e.g., SSLEngine, algorithm, digest). The Javadoc provides some clarity, but the code itself feels disoriented. Line length is reasonable for the constants, but the single-line import and declaration of constants add noise. The method signatures are concise, but the awkward naming breaks the natural reading flow. Overall, the structure is acceptable for an API stub, but the inconsistent and misleading names significantly reduce readability.
Run 1
Code Structure: Logically organized as imports, interface constants, and two documented methods, though constants could be visually grouped. Nesting: Flat, with no nested control flow. Clarity of intent: Constants and documentation explain the cryptographic purpose, but method names emit/deliver and parameter names status/pendingRequest/group/config/count obscure signing and decryption semantics. Javadoc parameter names do not match declarations, undermining clarity. Code length: Concise for an interface; repeated constant aliases are reasonable API definitions. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Predictable top-to-bottom organization, but documentation-to-signature inconsistencies interrupt comprehension, and minimal spacing around imports reduces visual separation.
Run 2
Code Structure: Logically organized as an interface with constants followed by two documented operations. Nesting: Flat, with no nested control flow. Clarity of intent: Significantly weakened by misleading method names (emit, deliver) and parameter names (status, pendingRequest, group, config, count). Javadoc describes signing and decryption but references parameter names absent from the actual signatures, forcing readers to infer mappings. Code length: Appropriately concise; repetitive constants serve a legitimate API purpose. Action granularity: Each declaration occupies its own line, making individual elements easy to scan. Reading flow: Constants and documentation provide a natural progression, but documentation/signature inconsistencies interrupt comprehension. Overall, clean formatting and simple structure are undermined by ambiguous naming and inaccurate parameter documentation.
Run 3
Code Structure: The interface is logically organized into constants and two documented methods. Nesting: Flat declarations make it easy to scan. Clarity of intent: Cryptographic constants are descriptive, but emit and deliver obscure signing and decryption intent. Parameter names such as status, pendingRequest, group, config, and count are misleading, and the Javadoc parameter names do not match the actual signatures. Code length: Reasonably concise; the lengthy constant list is justified by the supported algorithms. Action granularity: Each declaration occupies its own line, with no combined actions. Reading flow: Constants followed by method documentation provide a natural progression, but inconsistent naming forces readers to reconcile documentation with signatures. Missing spacing around imports and informal introductory wording slightly reduce polish.