Thank you, that clears things up a lot!
Best Regards
Magnus Reftel
On 2024/02/19 15:57:49 Gary Gregory wrote:
> Hi Magnus and all,
>
> This was discovered through fuzz testing, basically if some bits in
> some parts of a file follow some pattern, then the infinite loop kicks
> in. It only
Ses also https://github.com/google/oss-fuzz/pull/11616/files
Gary
On Mon, Feb 19, 2024 at 3:57 PM Gary Gregory wrote:
>
> Hi Magnus and all,
>
> This was discovered through fuzz testing, basically if some bits in
> some parts of a file follow some pattern, then the infinite loop kicks
> in. It
Hi Magnus and all,
This was discovered through fuzz testing, basically if some bits in
some parts of a file follow some pattern, then the infinite loop kicks
in. It only happens if your Commons Compress client code decides to
parse a DUMP file.
The ticket
Hi,
Are there any more details on this issue? For instance, under what
circumstances would an application that uses the commons-compress library be
vulnerable? The subject line hints that the flaw is specific to the Dump
format. Is that correct? Are there any options that need to be
Hi Oliver,
What you point out is documented in the release notes [1] and the
site's changes section [2].
Don't confuse binary compatibility (formally defined by the JLS and we
follow) with "drop-in replacement" which can mean different things to
different people.
If you update the version of
Hello Gary,
Thank you for this release.
I'd like to point out to users of Commons Compress that this version
1.26.0 introduce a *new* dependency to commons-codec (for which it uses
the latest 1.16.1).
https://central.sonatype.com/artifact/org.apache.commons/commons-compress/dependencies
So
