dependabot[bot] opened a new pull request, #27896: URL: https://github.com/apache/camel/pull/27896
Bumps [io.github.classgraph:classgraph](https://github.com/classgraph/classgraph) from 4.8.196 to 4.8.198. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/classgraph/classgraph/releases";>io.github.classgraph:classgraph's releases</a>.</em></p> <blockquote> <h2>ClassGraph 4.8.198</h2> <p><strong>ClassGraph 5.0.0 is coming shortly</strong>, and requires JDK 17 or newer. 4.8.198 is a bugfix release on the 4.x maintenance branch. As before, most of the bugs listed here were found by Claude through careful code analysis, and were fixed on the v5 branch and backported to v4.</p> <h2>Behavior changes</h2> <ul> <li> <p><strong>The worker timeout now stops a scan that has stopped making progress, instead of letting it hang.</strong> In 4.8.197 the timeout was applied only once every work unit had finished or one had failed, so a worker stuck on a hung network mount, or a thread waiting for another thread to open the same classpath element or jarfile, hung the scan forever. The timeout set by <code>setWorkerTimeout()</code> (1 minute by default) now counts from the last progress: a work unit finishing, bytes downloaded from a URL or inflated from a nested jar, bytes written to a temporary file, or an entry listed in a directory. So a slow download that keeps delivering bytes does not time out. When the timeout runs out the scan fails with <code>ClassGraphException</code>; reading a local jarfile or classfile does not count as progress, so a read that blocks for longer than the timeout also fails the scan. The wait is made in slices of a tenth of the timeout or 1 second, whichever is shorter, an d a pause of the whole JVM, such as <code>SIGSTOP</code> or a debugger breakpoint that suspends all threads, counts as at most one slice. A breakpoint that suspends only one worker thread is not such a pause: set a longer timeout, or 0, while debugging a scan.</p> </li> <li> <p><strong>A scan that fails no longer leaves the calling thread interrupted.</strong> In 4.8.197 a failure such as a worker timeout set the interrupt status of the thread that called <code>scan()</code>, so the next blocking call on that thread threw <code>InterruptedException</code>, a retry of the scan failed with "Scan interrupted", and a <code>FailureHandler</code> ran with its thread interrupted. The thread is now interrupted only when the scan itself was interrupted.</p> </li> <li> <p><strong>An interrupted thread no longer breaks a jarfile for every other thread.</strong> Unless <code>enableMemoryMapping()</code> is set, all reads of a jarfile share one <code>FileChannel</code>, and the JDK closes the channel when an interrupted thread reads from it, so in 4.8.197 every later read of that jarfile failed with <code>ClosedChannelException</code> until the <code>ScanResult</code> was closed. Now an interrupted thread gets an <code>InterruptedIOException</code> before it reads, and a channel closed this way is reopened for the other threads.</p> </li> <li> <p><strong>On Tomcat, the classpath now holds only what the webapp classloader loads from.</strong> The webapp classloader loads a class or resource <code>x</code> from the webapp resource <code>/WEB-INF/classes/x</code>, but 4.8.197 also reported the webapp root, its static content, <code>index.jsp</code>, <code>WEB-INF/web.xml</code>, the resource jars, and the whole of a packed WAR file. Now a resource set mounted at <code>/WEB-INF/classes</code> (such as the jars in <code>WEB-INF/lib</code>) is on the classpath as a whole, the webapp directory or WAR file only from its <code>WEB-INF/classes</code> directory, and a static-only or other resource set not at all.</p> </li> <li> <p><strong>A classloader handler that throws is now logged and skipped, instead of failing the scan.</strong> ClassGraph reads the internals of container classloaders by reflection, and in 4.8.197 a <code>RuntimeException</code> or <code>LinkageError</code> from any handler failed the scan with "Uncaught exception during scan" (<a href="https://redirect.github.com/classgraph/classgraph/issues/651";>#651</a>, <a href="https://redirect.github.com/classgraph/classgraph/issues/891";>#891</a>). The classpath entries found by the other handlers are now kept. The Tomcat handler also reads the delegation order through <code>getDelegate()</code> when a subclass hides Catalina's <code>delegate</code> field, which caused a <code>ClassCastException</code> before.</p> </li> <li> <p><strong>Running out of memory or stack while opening a jarfile now stops the scan.</strong> In 4.8.197 an <code>OutOfMemoryError</code> or <code>StackOverflowError</code> thrown while opening a jarfile, for example while inflating a nested jar into memory, only skipped that jarfile, so the scan returned normally with its classes missing and only the verbose log said why. These errors now fail the scan.</p> </li> <li> <p><strong>When scanning is extended to an external superclass, interface or annotation, ClassGraph now reads the copy of its classfile that the JVM would load.</strong> 4.8.197 looked first in the classpath element of the class that referred to it, so an application jar holding its own copy of a class that is earlier on the classpath gave that copy's superclass and interfaces, and with two such copies the result could change from run to run. The classfile is now looked up strictly in classpath order. During a scan, each directory classpath element remembers which package directories it does not have, so a long list of directories before the jar that holds the external classes does not slow the scan down; the memory is released once the classfiles have been scanned.</p> </li> <li> <p><strong>An annotation array value whose type has changed is now kept as <code>Object[]</code>, instead of throwing.</strong> When an annotation class was recompiled after the class that uses it, with an element changed between an array type and another type, 4.8.197 threw <code>IllegalArgumentException</code> or <code>NullPointerException</code> when any element of that annotation was read, or returned an array of nulls, and a changed <code>@Repeatable</code> container made the whole scan fail. Now only the changed element is affected: it is returned as the <code>Object[]</code> array read from the classfile, and reading it from an annotation proxy throws <code>ClassCastException</code>.</p> </li> <li> <p><strong>A repeated annotation on a private field, a private method or a parameter of a private method no longer makes <code>getClassesWithFieldAnnotation()</code>, <code>getClassesWithMethodAnnotation()</code> or <code>getClassesWithMethodParameterAnnotation()</code> return the subclasses of its class.</strong> A private member is not inherited, and these methods already left out the subclasses for an annotation that is not repeated.</p> </li> <li> <p><strong>A method type signature that does not parse is now treated as absent.</strong> In 4.8.197 <code>MethodInfo#getParameterInfo()</code> and <code>MethodInfo#toString()</code> threw <code>IllegalArgumentException</code> for such a method, which made a scan with <code>enableInterClassDependencies()</code> fail, <code>TypeSignature#resolveTypeVariables</code> threw too, and <code>getTypeDescriptor()</code> threw on the first call for a method with type annotations. These methods now use the type descriptor instead. <code>getTypeSignature()</code> still throws <code>IllegalArgumentException</code> for a signature that does not parse.</p> </li> <li> <p><strong>A classfile is now scanned as a class only when its path is a class name the JVM accepts.</strong> In 4.8.197 a stray file <code>x.Y.class</code> was also taken to be class <code>x.Y</code>, so with <code>x/Y.class</code> present as well the whole scan failed with "Class x.Y should not have been scheduled more than once". A classfile whose path below its package root has an empty segment, or a segment containing <code>.</code>, <code>;</code> or <code>[</code>, is now listed only as a resource. A package such as <code>my-pkg</code>, which is not a Java identifier but which the JVM loads, is still scanned.</p> </li> <li> <p><strong>A classfile that names its superclass, an interface, or an inner, outer or enclosing class illegally is now skipped, instead of failing the scan.</strong> In 4.8.197 a name such as <code>p/S;</code>, or an array class whose element name contains <code><</code>, failed the whole scan with "Uncaught exception during scan", and a name such as <code>p//S</code> created a class that no JVM can load. Such a classfile, which the JVM refuses to load, is now logged and skipped, while an array class named only as an inner class or as an <code>EnclosingMethod</code> class, which the JVM accepts, is ignored and the class is kept.</p> </li> <li> <p><strong>An illegal class name that a classfile refers to only as a dependency no longer costs the class.</strong> With <code>enableInterClassDependencies()</code>, 4.8.197 failed the scan for a constant pool class name such as <code>Q;</code>, and it skipped the whole class for an array class such as <code>[Lp/A<x>;</code>, which the JVM accepts. The class is now kept: the illegal name is logged and left out of the dependencies, and an array class adds its element class.</p> </li> <li> <p><strong>An annotation whose type name is illegal or missing is now skipped, and the class that carries it is kept.</strong> In 4.8.197 such an annotation could fail the whole scan, create a class whose name is empty, or give an <code>AnnotationInfo</code> whose name is null. The JVM does not check annotation type names and loads such a class, so ClassGraph now leaves out only that annotation, and any annotation whose element values hold one.</p> </li> <li> <p><strong>Limits on nesting now keep a crafted classfile from overflowing the stack.</strong> In 4.8.197 a classfile with type arguments nested thousands deep, annotation values nested thousands deep, or an array type with thousands of dimensions made the scan fail with <code>StackOverflowError</code>. A type signature whose type arguments nest more than 100 deep is now treated as a signature that does not parse, a classfile whose annotation values nest more than 255 deep is skipped, and an array type with more than 255 dimensions, which the JVM never allows, is rejected in the same ways.</p> </li> <li> <p><strong>A classfile longer than 64 MB is now skipped.</strong> 4.8.197 buffered a classfile up to the length it declared for each attribute to skip, up to 2 GB, so a jar of about 1 MB could make a scan allocate about 800 MB, and a larger one could fail the scan with <code>OutOfMemoryError</code>. Reading past 64 MB now throws an <code>IOException</code>, and the classfile is logged and skipped; the largest of 1.28 million classfiles in a large Maven repository is 1.1 MB.</p> </li> <li> <p><strong>The jarfiles nested in a jarfile may now inflate to at most 100 times the size of that jarfile, or 256 MB, whichever is larger, in all.</strong> 4.8.197 had no limit, so a jar of under 100 KB could make a scan inflate a nested jar of any size into memory or into a temporary file. A nested jar that would go past the limit is skipped, as any jar that cannot be opened is. Real nested jars inflate to between 1 and 3 times their compressed size.</p> </li> <li> <p><strong>Temporary files are now readable only by their owner.</strong> ClassGraph writes a nested jar too large to buffer in memory, or a jar downloaded from a URL, to a temporary file. In 4.8.197 that file got the default permissions, which usually let every local user read it in a shared <code>/tmp</code> (the same flaw as CVE-2020-15250); it is now mode 0600 on POSIX systems, and on Windows it takes the access control list of the temporary directory, as before.</p> </li> <li> <p><strong>A temporary directory that cannot be used no longer breaks temporary files for the rest of the JVM.</strong> The JDK sets up its temporary directory once, the first time a temporary file is created in the JVM, and if that fails, every later attempt in the JVM fails with <code>NoClassDefFoundError</code>. In 4.8.197, when the application had cleared <code>java.io.tmpdir</code>, ClassGraph's temporary file for a nested jar could be that first attempt, which broke <code>File.createTempFile</code> for the application too, on JDK 8 and on JDK 17. On JDK 8 to 15, where the JDK reads the property as it is at that moment, ClassGraph now checks the property first, and throws an <code>IOException</code> without touching the JDK's setup when it is unset or names a directory that cannot be represented in the encoding used for filenames (such as a non-ASCII name under the C locale on Linux). From JDK 16 the JDK uses the value it read at startup, and ClassGraph leaves the choice to t he JDK. Any <code>ExceptionInInitializerError</code> or <code>NoClassDefFoundError</code> from the JDK's setup is reported as an <code>IOException</code>. In every case ClassGraph skips only the jarfile it was writing, as before. One case is stricter than before, on JDK 8 to 15 only: if the property is cleared after the JDK has already created a temporary file, the JDK could still create one, but ClassGraph now gives an <code>IOException</code>.</p> </li> </ul> <h2>Bug fixes: annotations</h2> <ul> <li> <p><strong>Reading the values of the same annotation from two threads at once no longer throws <code>NullPointerException</code> or stores a partly filled array.</strong> An array value is converted to its element type when it is first read, and two threads could do this at the same time, so a value such as <code>[1, 2, 3]</code> could be left as <code>[1, 0, 0]</code> for good. The conversion is now done once, under a lock.</p> </li> <li> <p><strong>Hashing or comparing an <code>AnnotationInfo</code> while another thread first reads its values no longer gives a wrong hash code or <code>NullPointerException</code>.</strong> <code>hashCode()</code>, <code>equals()</code> and <code>compareTo()</code> now convert the values before they read them. A wrong hash code left an annotation in the wrong bucket of a <code>HashSet</code> for good.</p> </li> </ul> <h2>Bug fixes: paths in jarfiles</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/classgraph/classgraph/commit/4dd6f73ada8cf754f7c6aec13095f221d2a93469";><code>4dd6f73</code></a> [maven-release-plugin] prepare release classgraph-4.8.198</li> <li><a href="https://github.com/classgraph/classgraph/commit/0a85055087281622515f85b61ab858a24b618e54";><code>0a85055</code></a> Make two tests pass on Windows and macOS, and tighten two others</li> <li><a href="https://github.com/classgraph/classgraph/commit/80e68eb171d003c16c3bfcbcc833d2849b54fb59";><code>80e68eb</code></a> Say which breakpoints pause the whole JVM</li> <li><a href="https://github.com/classgraph/classgraph/commit/44260d26dfd391be34aa9ddb4afed7c0fa648e9a";><code>44260d2</code></a> Test that scanning a directory reports progress for each entry</li> <li><a href="https://github.com/classgraph/classgraph/commit/0f2a1852747cb8af9b49d77648ae1d2691ab8e55";><code>0f2a185</code></a> Report progress for a byte read on its own while reading a jarfile</li> <li><a href="https://github.com/classgraph/classgraph/commit/907fa6910265a92d6284b68113bd38a746210c0a";><code>907fa69</code></a> Say what skipping the java.io.tmpdir check can break</li> <li><a href="https://github.com/classgraph/classgraph/commit/496bfb21cddce81c4504a9bf9ece994567766066";><code>496bfb2</code></a> Test the worker timeout's untested paths, and fix what it says of pauses</li> <li><a href="https://github.com/classgraph/classgraph/commit/0e0eba788983201901e904c63047aa5cadc1de11";><code>0e0eba7</code></a> Rewrap the comments that 3e0d65dbd left too long</li> <li><a href="https://github.com/classgraph/classgraph/commit/3e0d65dbd876a15f6b44e8c4a09185cd24a707ba";><code>3e0d65d</code></a> Say which JDK calls read java.io.tmpdir before JDK 16</li> <li><a href="https://github.com/classgraph/classgraph/commit/8e1460799917c38c32c7d622b4a7a6e2f6006091";><code>8e14607</code></a> Forget the package directories a scan looked up once it is done</li> <li>Additional commits viewable in <a href="https://github.com/classgraph/classgraph/compare/classgraph-4.8.196...classgraph-4.8.198";>compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
