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[] a(SSLEngine a, int b, byte[] c) 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[] b(SSLEngine d, byte[] e) throws Exception;
}
Run 1
The code is mostly readable and logically structured: imports and class declaration are straightforward, constants are grouped, and documentation is present. However, its readability is significantly hurt by the last two method signatures, which use meaningless parameter names like 'a', 'b', 'c', 'd', and 'e', and method names 'a' and 'b'. This makes the intent unclear despite the Javadoc. The constant declarations are repetitive but acceptable for this purpose. No deep nesting or multi-action lines exist, so those criteria are fine. Overall legibility is moderate but compromised by non-descriptive identifiers.
Run 2
The code is well-structured as a clean interface with a clear purpose: customizing private key operations in OpenSSL. Constants are neatly grouped and consistently mapped to SSLPrivateKeyMethod values, aiding readability. Javadoc comments for both methods clearly describe parameters, return values, and exceptions, contributing to intent clarity. The file is concise and avoids unnecessary logic. However, readability is negatively impacted by the use of meaningless parameter names like 'a', 'b', 'c', 'd', and 'e' in method signatures, which obscures the methods' contracts despite the Javadoc. The reading flow is slightly interrupted by the long list of constants but remains logically organized. Overall, it is highly readable, with the main drawback being poor parameter naming.
Run 3
The code is fundamentally clear in structure and purpose, with good Javadoc, but its readability is significantly undermined by meaningless parameter names and method names. The constants are logical and concise. However, methods 'a(SSLEngine a, int b, byte[] c)' and 'b(SSLEngine d, byte[] e)' provide no clarity of intent; a reader cannot understand what the parameters represent without reading the full Javadoc. This forces context-switching and harms the reading flow. Nesting is flat, action granularity is one per line, and the length is appropriate for an interface. The primary issue is that the abbreviated method and parameter names fail to convey purpose, making the code appear obfuscated despite its organized structure.
Run 1
Code Structure: The interface logically separates constants from two documented operations. Nesting: Flat declarations with no nested control flow are easy to scan. Clarity of intent: Descriptive constants and Javadocs explain the purpose, but method names a and b and single-letter parameters obscure the API. Javadoc parameter names also do not match the declarations, undermining clarity. Code length: Appropriately concise for an interface; repeated constants are justified. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Constants followed by signing and decryption operations create a natural sequence, although minimal spacing around imports and cryptic method signatures interrupt readability.
Run 2
Code Structure: The interface logically separates algorithm constants from signing and decryption operations. Nesting: Flat declarations make it easy to scan. Clarity of intent: Descriptive constants and Javadoc explain the purpose, but method names a/b and parameter names a–e obscure the API. Javadoc parameter names do not match the signatures, further reducing clarity. Code length: Appropriate for a small interface; repetitive constants serve a legitimate purpose. Action granularity: Each constant or method declaration occupies its own line. Reading flow: Constants followed by documented methods provide a natural progression, although missing spacing around imports and cryptic identifiers interrupt readability.
Run 3
Code Structure: Logically organized into imports, an interface, constants, and two documented methods. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive constants and Javadoc explain the purpose, but method names a/b and parameter names a–e obscure meaning. Javadoc parameter names do not match the actual declarations, further reducing clarity. Code length: Appropriately concise for an interface; the repeated constants serve a clear purpose. Action granularity: Each declaration occupies its own line, making individual elements easy to scan. Reading flow: Constants followed by operations provide a natural progression, though missing spacing around imports and cryptic method signatures interrupt readability.