Fix FileInputStream leak in decodeCrlFile causing file handle exhaustion on Windows

[Copilot]

The decodeCrlFile() method in FileBasedTrustListManager creates a FileInputStream without closing it, causing file handle leaks that prevent CRL deletion on Windows.

Changes:

• Wrap FileInputStream in try-with-resources for automatic closure
• Consolidate duplicate catch blocks into multi-catch

Before:

private static Optional<List<X509CRL>> decodeCrlFile(Path path) {
  try {
    CertificateFactory factory = CertificateFactory.getInstance("X.509");
    Collection<? extends CRL> crls = factory.generateCRLs(new FileInputStream(path.toFile()));
    // Stream never closed - file handle leak
    return Optional.of(crls.stream()...);
  } catch (CertificateException | FileNotFoundException | CRLException e) {
    // ...
  }
}

After:

private static Optional<List<X509CRL>> decodeCrlFile(Path path) {
  try {
    CertificateFactory factory = CertificateFactory.getInstance("X.509");
    try (FileInputStream inputStream = new FileInputStream(path.toFile())) {
      Collection<? extends CRL> crls = factory.generateCRLs(inputStream);
      return Optional.of(crls.stream()...);
    }
  } catch (CertificateException | CRLException | IOException e) {
    // ...
  }
}

Pattern now matches decodeCertificateFile() which already handles resources correctly.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• repo.eclipse.org
  • Triggering command: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.17-10/x64/bin/java /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.17-10/x64/bin/java --enable-native-access=ALL-UNNAMED -classpath /usr/share/apache-maven-3.9.12/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/usr/share/apache-maven-3.9.12/bin/m2.conf -Dmaven.home=/usr/share/apache-maven-3.9.12 -Dlibrary.jansi.path=/usr/share/apache-maven-3.9.12/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/milo/milo org.codehaus.plexus.classworlds.launcher.Launcher -q clean compile -pl opc-ua-stack/stack-core (dns block)
  • Triggering command: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.17-10/x64/bin/java /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.17-10/x64/bin/java --enable-native-access=ALL-UNNAMED -classpath /usr/share/apache-maven-3.9.12/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/usr/share/apache-maven-3.9.12/bin/m2.conf -Dmaven.home=/usr/share/apache-maven-3.9.12 -Dlibrary.jansi.path=/usr/share/apache-maven-3.9.12/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/milo/milo org.codehaus.plexus.classworlds.launcher.Launcher -q spotless:apply -pl opc-ua-stack/stack-core (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Unclosed FileInputStream causes file handle leak and prevents CRL deletion on Windows</issue_title>
<issue_description>Component: org.eclipse.milo.opcua.stack.core.security.FileBasedTrustListManager

Method:
private static Optional<List> decodeCrlFile(Path path)

Problem:
The method creates a FileInputStream using:
new FileInputStream(path.toFile())
and passes it to:
factory.generateCRLs(...)
but never closes the stream.

This results in:
File handle leak: The stream remains open until garbage collection, which is non-deterministic.
Windows-specific issue: On Windows, an open file handle prevents deletion or renaming of the file, causing Files.delete(...) to fail with:
java.nio.file.FileSystemException: The process cannot access the file because it is being used by another process

Impact:

CRL files cannot be deleted or replaced immediately after being read.
Causes intermittent failures in trust list updates and cleanup operations.
May lead to resource exhaustion if many CRLs are processed.

Root Cause:
Missing try-with-resources or explicit close() call for FileInputStream.
Suggested Fix:
Wrap the FileInputStream in a try-with-resources block:
try (InputStream in = Files.newInputStream(path)) { Collection<? extends CRL> crls = factory.generateCRLs(in); ... }
</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Unclosed FileInputStream causes file handle leak and prevents CRL deletion on Windows #1680

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.