Error Prone Documentation

The InsecureCryptoUsage checker flags three specific classes of cryptographic vulnerabilities in Java code:

1. Insecure Cipher Configurations:

   • Creating javax.crypto.Cipher instances using default settings or the insecure ECB mode.
   • Note that Cipher.getInstance(AES) defaults to ECB mode in Java.
   • Dynamically constructed transformation strings are flagged to prevent concealing ECB mode.
   • IES-based cipher algorithms are flagged because their implementations use ECB mode.

2. Insecure Diffie-Hellman (DH) Implementations:

   • Flags any operation involving the Diffie-Hellman protocol on prime fields, as these are often exploitable.
   • Recommendation: Use Elliptic Curve Diffie-Hellman (ECDH) instead, as it is considered secure.

3. Insecure DSA Signatures:

   • Flags all cryptographic operations involving DSA (Digital Signature Algorithm) due to vulnerabilities in certain library configurations that accept invalid signatures.

The RedundantNullCheck pattern flags null checks (e.g., x == null or x != null) performed on expressions that are statically determined to be non-null. This occurs when:

1. Language semantics guarantee the value is non-null.
2. The code is within a @NullMarked scope and the type is not explicitly annotated with @Nullable.

This helps clean up code and reinforces the contracts provided by nullness annotations.

import org.jspecify.annotations.NullMarked;
import org.jspecify.annotations.Nullable;

@NullMarked
class MyClass {
  void process(String definitelyNonNull) {
    // BUG: RedundantNullCheck
    if (definitelyNonNull == null) {
      System.out.println("This will never happen");
    }
  }

  String getString() {
    return "hello";
  }

  @Nullable String getNullableString() {
    return null;
  }

  void anotherMethod() {
    String s = getString();
    // BUG: RedundantNullCheck (s is known to be non-null)
    if (s == null) {
      System.out.println("Redundant check");
    }

    String nullableStr = getNullableString();
    if (nullableStr == null) { // This check is NOT redundant
      System.out.println("Nullable string might be null");
    }
  }
}

The ErroneousThreadPoolConstructorChecker bug pattern identifies cases where a ThreadPoolExecutor is constructed with an unbounded workQueue. When the queue is unbounded, the pool size will never exceed the corePoolSize, rendering the maximumPoolSize parameter ineffective.

To fix this, you should either:

1. Set corePoolSize equal to maximumPoolSize if you intend to use an unbounded queue.
2. Use a bounded queue (e.g., new LinkedBlockingQueue<>(capacity)) to allow the pool to scale up to the maximumPoolSize when the queue fills up.

// Bad: maximumPoolSize is ignored because the queue is unbounded
new ThreadPoolExecutor(
    /* corePoolSize= */ 1,
    /* maximumPoolSize= */ 10,
    /* keepAliveTime= */ 60,
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>());

// Good: corePoolSize and maximumPoolSize are equal
new ThreadPoolExecutor(
    /* corePoolSize= */ 10,
    /* maximumPoolSize= */ 10,
    /* keepAliveTime= */ 60,
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>());

// Good: Using a bounded queue allows scaling to maximumPoolSize
new ThreadPoolExecutor(
    /* corePoolSize= */ 1,
    /* maximumPoolSize= */ 10,
    /* keepAliveTime= */ 60,
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(QUEUE_CAPACITY));