Thank you Peter for the patch. Now in git master.
As to whether we should change the default, I don't know if we have
the right kind of test that would detect if changing the default
causes a problem.
Changing the default to true (locally) causes the build to XXX but
that does not mean we have th
Thanks for the reminder, Peter. That rings a bell... vaguely.
Can this test pass by configuring the input stream differently?
Gary
On Sat, Mar 9, 2024 at 1:21 PM Peter Hull wrote:
>
> On Sat, 9 Mar 2024 at 14:33, Gary Gregory wrote:
> >
> > If you want to help in Commons COMPRESS-land, please
On Sat, 9 Mar 2024 at 18:19, Peter Hull wrote:
> There's another constructor for BZip2CompressorInputStream which
> allows for this, it's not the default.
Specifically, the patch below makes the test pass. Whether this should
be default for the one-arg constructor is a matter for discussion.
Peter
On Sat, 9 Mar 2024 at 14:33, Gary Gregory wrote:
>
> If you want to help in Commons COMPRESS-land, please see
> https://issues.apache.org/jira/browse/COMPRESS-651
I swear I looked into this a while ago, and the issue was pbzip2 works
by compressing the source in chunks, in parallel, then cat'ing t
I can't add to the JIRA bug but I had a quick play on WSL (debian),
Java 21, compress 1.25.0 and found:
Using dd if=/dev/random I could create a big file, compress it with
bzip2 and then decompress it with BZip2CompressorInputStream , no
problems
Same file compressed with pbzip2 was truncated at 90
I'll look into it (tomorrow).
Gary
On Thu, Jan 4, 2024, 4:55 PM Chad Preisler wrote:
> Hello,
>
> I've created a bug report for a problem I ran into with the snappy output
> stream. I've created a pull request with a fix and unit tests for the
> issue. Please let me know if there is additional
Hi Hans,
Thanks for pointing that out. I had a look at the latest version of that
page in GitHub, and it looks like some CVEs were added post-release:
https://github.com/apache/commons-compress/blob/master/src/site/xdoc/security-reports.xml
I tried building it locally to deploy a new version, but
Thank you Matt!
On Thu, May 5, 2022, 23:52 Matt Juntunen wrote:
> Hello,
>
> I've created a PR with a fix for that test. However, I'm not familiar
> enough with the tar format to know if this is all that's needed or if
> there is a deeper issue that needs to be addressed.
>
> Regards,
> Matt J
>
Hello,
I've created a PR with a fix for that test. However, I'm not familiar
enough with the tar format to know if this is all that's needed or if
there is a deeper issue that needs to be addressed.
Regards,
Matt J
On Thu, May 5, 2022 at 8:41 PM Gary Gregory wrote:
>
> Hi All,
>
> I discovered
The best way forward is for you to create a PR on GitHub so we can all see
what this would look like.
Thank you,
Gary
On Thu, Nov 11, 2021, 03:08
wrote:
>
> PKWARE-APPNOTE-6.3.9.txt states:
>
> 4.3.14 Zip64 end of central directory record
> ...
> total number of entries in the central dir
Our pack200 support was picked up and integrated from the now defunct
Apache Harmony; beyond that, we all have to learn it as it lays in our
repo. I'm afraid I do not have much to offer beyond moral support and PR
reviews; -) I'll learn and review as you go...
Gary
On Fri, Nov 5, 2021, 19:04 Eric
Where in the current implementation might one look for these sorts of
things?
In the quoted code seems to focus on the SegmentHeader related details
would something around this be needed?
I see some of the major/minor may be based on read code and relate to the
Codec in use.
While looking for Seg
Some sample pack200 files should also be part of tests.
Gary
On Thu, Oct 28, 2021, 10:16 Gary Gregory wrote:
> You'll have to figure out the implementation details but I will be happy
> to review PRs on GitHub.
>
> Gary
>
> On Thu, Oct 28, 2021, 08:32 Eric Bresie wrote:
>
>> In this particular
You'll have to figure out the implementation details but I will be happy to
review PRs on GitHub.
Gary
On Thu, Oct 28, 2021, 08:32 Eric Bresie wrote:
> In this particular case, there were packed modules which had major / minor
> versions not equal to the Major version 7 or minor version 150 sup
In this particular case, there were packed modules which had major / minor
versions not equal to the Major version 7 or minor version 150 supported in
the code.
This results in the exception, preventing it from unpacking. The need is
to be able to unpack an older packed file.
As I understand it,
There is not. The intent of the current code is simply to provide
functionality that was dropped from the JRE.
What newer versions and how are they different?
Gary
On Tue, Oct 26, 2021, 13:49 Eric Bresie wrote:
> While trying to unpack an older generated pack file, it was noted that
> Pack200
I updated the release notes and site.
Gary
On Fri, Jul 30, 2021 at 7:26 AM Bruno P. Kinoshita wrote:
>
> Agreed. Just document in the release notes.
>
>
>
>
> On Friday, 30 July 2021, 4:21:01 pm NZST, Gary Gregory
> wrote:
>
> It seems to me we just need to update our release notes.
>
>
Agreed. Just document in the release notes.
On Friday, 30 July 2021, 4:21:01 pm NZST, Gary Gregory
wrote:
It seems to me we just need to update our release notes.
Gary
On Fri, Jul 30, 2021, 00:00 PeterLee wrote:
> Hi all,
>
> There is a new issue Compress-583 reporting Compress
It seems to me we just need to update our release notes.
Gary
On Fri, Jul 30, 2021, 00:00 PeterLee wrote:
> Hi all,
>
> There is a new issue Compress-583 reporting Compress 1.21 generated tars
> are not byte-to-byte
> same with older versions.And the generated tars are also different in
> diffe
This is great work. Thanks.
cheers,
Lee
On Sat, Jul 3, 2021 at 10:15 PM Stefan Bodewig wrote:
> On 2021-07-03, Stefan Bodewig wrote:
>
> > I assume the code originates from
> >
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack200/src/main/
> > and I'd look int
Everything looks great. :)
On Sat, Jul 3, 2021 at 5:57 PM Stefan Bodewig wrote:
> Hi all
>
> is there anything you want to work on or can we go ahead with cutting a
> new Compress release in about a week?
>
> There are some test coverage and javadoc issues that need to get
> resolved but other t
Nice!
Gary
On Sat, Jul 3, 2021, 10:15 Stefan Bodewig wrote:
> On 2021-07-03, Stefan Bodewig wrote:
>
> > I assume the code originates from
> >
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack200/src/main/
> > and I'd look into porting the tests from
> >
> htt
On 2021-07-03, Stefan Bodewig wrote:
> I assume the code originates from
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack200/src/main/
> and I'd look into porting the tests from
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack
Go for it :-)
Gary
On Sat, Jul 3, 2021, 05:57 Stefan Bodewig wrote:
> Hi all
>
> is there anything you want to work on or can we go ahead with cutting a
> new Compress release in about a week?
>
> There are some test coverage and javadoc issues that need to get
> resolved but other than that at
Good idea, I mistakenly thought our coverage was better.
Gary
On Sat, Jul 3, 2021, 05:50 Stefan Bodewig wrote:
> Hi
>
> our current pack200 tests don't seem to cover much of the pack200 code
> imported from harmony and the overall test coverage of Compress as a
> whole has dropped significantly
On 2021-07-03, Gary Gregory wrote:
> This is the approach I've taken: I merged the pack200 branch into
> master as is.
Thank you
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
On Fri, Jul 2, 2021 at 11:19 AM Stefan Bodewig wrote:
>
> On 2021-06-12, Gary Gregory wrote:
>
> > Please have a look at the pack200 branch if you want, there are still
> > Javadoc TODOs but it's all there.
>
> Just so we get this into this list's archive properly: I've propsed a
> few changes in
On 2021-06-12, Gary Gregory wrote:
> Please have a look at the pack200 branch if you want, there are still
> Javadoc TODOs but it's all there.
Just so we get this into this list's archive properly: I've propsed a
few changes in https://github.com/apache/commons-compress/pull/210 but
completely le
Adding my two cents here...
It's very important to me as a user and developer to have informative
errors. If I use compress in my application and a raw NPE or out of bounds
exception flies out of the code with little to no context and makes it out
to the end user, then I am going to be getting a c
On 6/29/21 8:08 AM, Stefan Bodewig wrote:
On 2021-06-29, Miguel Munoz wrote:
Catching all RuntimeExceptions and wrapping them in an IOException
looks like the cleanest solution. RuntimeExceptions usually mean bugs,
so if the archive code is throwing them due to a corrupted archive, it
makes
> [...]
> > One is "sorry, this is an invalid archive" while the other is "something
> > > went wrong reading the archive - printStackTrace". If that distinction is
> > > not important to you - so be it. To me that's a big difference.
> >
> > Never said such a thing.
> >
>
> Not sure what "thing" y
> >> That certainly doesn't prevent anybody else from trying to find a
> >> compromise :-)
>
> > It feels like Optionals could be a compromise.
>
> I must admit I've lost track of the later discussion threads. If you
> mean that we'd return Optional<> results, this would become an entirely
> differ
On 2021-07-01, Torsten Curdt wrote:
>> That certainly doesn't prevent anybody else from trying to find a
>> compromise :-)
> It feels like Optionals could be a compromise.
I must admit I've lost track of the later discussion threads. If you
mean that we'd return Optional<> results, this would be
> That certainly doesn't prevent anybody else from trying to find a
> compromise :-)
>
It feels like Optionals could be a compromise.
> > So IllegalArgumentException is not from the early Java days?
>
> It is, so what?
> It's the exception I use 99% of the time (to signal failed precondition)?
> It's a runtime exception.
>
When I quote standard exceptions you said:
"if you quote design decisions that date back from the early Ja
Le jeu. 1 juil. 2021 à 11:31, Torsten Curdt a écrit :
>
> > I'm not sure what you refer to exactly,
>
>
> The various links from
>
> https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html
>
> or even
>
> https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html
>
>
> > but
> I'm not sure what you refer to exactly,
The various links from
https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html
or even
https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html
> but I noted already that not all
> references are equal, especially if you quot
Le jeu. 1 juil. 2021 à 02:27, Torsten Curdt a écrit :
>
> >
> > "If there is runtime exception there is a bug in the code"
> >
> > I don't think that's correct because IllegalArgumentException is a
> > RuntimeException.
>
>
> I have a hard time following that causality. The way I've seen this
> ex
>
> "If there is runtime exception there is a bug in the code"
>
> I don't think that's correct because IllegalArgumentException is a
> RuntimeException.
I have a hard time following that causality. The way I've seen this
exception used mainly is in case of program errors, not in case of input
va
"If there is runtime exception there is a bug in the code"
I don't think that's correct because IllegalArgumentException is a
RuntimeException. See
https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalArgumentException.html
Gary
On Wed, Jun 30, 2021, 16:50 Torsten Curdt wrote:
> >
> > It
>
> It is not the job of commons-compress to stop you from using a
> corrupt archive. If you choose to do so, then ...
>
I don't think that's what it is.
That would be more like getting an exception and continuing walking through
the archive.
If there is a parse exception there is a bug in the in
Am 30.06.21 um 14:41 schrieb Gary Gregory:
On Tue, Jun 29, 2021 at 4:24 PM Stefan Bodewig wrote:
Hi
I'm sorry, but I'm unable to see what would or would not work for the
people who chimed in. Short of calling for a vote, lets try with a poll
that could show whether there is some sort of so
On Tue, Jun 29, 2021 at 10:24 PM Stefan Bodewig wrote:
> (4) don't catch RuntimeExceptions at all, just document broken archives
> can cause arbitrary RuntimeExceptions and code that tries to read
> archives from untrusted sources is expected to deal with them
> itself.
Strongly in f
On 2021-06-29, Stefan Bodewig wrote:
> Options raised during the thread:
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> subclass) and throw the IOException
+1
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOException (possibly a subc
On Tue, Jun 29, 2021 at 4:24 PM Stefan Bodewig wrote:
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Short of calling for a vote, lets try with a poll
> that could show whether there is some sort of solution that is
> acceptable to everybod
Le mer. 30 juin 2021 à 11:55, PeterLee a écrit :
>
> > (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> >subclass) and throw the IOException
>
> -1
>
> I agree with sebb about this option - this may accidentally convert a bug
> into
> something else.
>
> > (2) catch o
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
>subclass) and throw the IOException
-1
I agree with sebb about this option - this may accidentally convert a bug
into
something else.
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOExcept
> So ideally Compress will return a CE for parsing errors, and that CE
> should give some context to the error.
> Care must be taken however not to catch every RTE, lest this hide a
coding bug.
+1 for this.
Lee
On Tue, Jun 29, 2021 at 7:57 PM sebb wrote:
> On Tue, 29 Jun 2021 at 12:16, Gary Gr
Le mer. 30 juin 2021 à 02:32, Bernd Eckenfels a écrit :
>
> I vote for the subclass of IOException - if you care about handling broken
> archives you would catch it,
Yes, but you can catch a runtime exception all the same.
An application that doesn't want to terminate abruptly must catch
all exc
:33:16 AM
To: Commons Developers List
Subject: Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions
Le mar. 29 juin 2021 à 22:24, Stefan Bodewig a écrit :
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Sh
Le mar. 29 juin 2021 à 22:24, Stefan Bodewig a écrit :
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Short of calling for a vote, lets try with a poll
> that could show whether there is some sort of solution that is
> acceptable to everybo
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> subclass) and throw the IOException
>
+0
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOException (possibly a subclass) and throw the IOException - allow
> the remaining RuntimeExce
On Tue, 29 Jun 2021 at 21:24, Stefan Bodewig wrote:
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Short of calling for a vote, lets try with a poll
> that could show whether there is some sort of solution that is
> acceptable to everybody.
On 2021-06-29, Miguel Munoz wrote:
> Catching all RuntimeExceptions and wrapping them in an IOException
> looks like the cleanest solution. RuntimeExceptions usually mean bugs,
> so if the archive code is throwing them due to a corrupted archive, it
> makes sense to wrap it in a checked exception.
> Recovery may not be possible for a single archive, but the caller may
> want to process multiple archives.
> (Or potentially try again, if the error was caused by a transient error
> [1])
>
> So ideally Compress will return a CE for parsing errors, and that CE
> should give some context to the er
On Tue, 29 Jun 2021 at 12:16, Gary Gregory wrote:
>
> The best reason to create a new IO exception is if you are going to catch
> it instead of the original and recover differently. I don't think that's
> the case here, there is no "recovery" possible on a corrupted archive. For
> my money, the ex
The best reason to create a new IO exception is if you are going to catch
it instead of the original and recover differently. I don't think that's
the case here, there is no "recovery" possible on a corrupted archive. For
my money, the exception can remain unchecked as it is unrealistic that
recove
Catching all RuntimeExceptions and wrapping them in an IOException looks like
the cleanest solution. RuntimeExceptions usually mean bugs, so if the archive
code is throwing them due to a corrupted archive, it makes sense to wrap it in
a checked exception. I would like to suggest creating a new c
Le lun. 28 juin 2021 à 08:52, Stefan Bodewig a écrit :
>
> On 2021-06-27, Gilles Sadowski wrote:
>
> > Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>
> >> As I said, we can as well document that each method could throw
> >> arbitrary RuntimeExceptions, but I don't believe we can list th
On 2021-06-27, Gilles Sadowski wrote:
> Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>> As I said, we can as well document that each method could throw
>> arbitrary RuntimeExceptions, but I don't believe we can list the kinds
>> of RuntimeExceptions exhaustively
> Why not?
> Listing a
Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>
> On 2021-06-27, Gilles Sadowski wrote:
>
> > Hi.
>
> >> [...]
>
> >> it seemed Gilles was opposed to this idea
>
> > Rather (IIRC) my last comment was that it was your choice as to
> > what the API should look like.
>
> Sorry, I didn't mean
Le dim. 27 juin 2021 à 19:05, Torsten Curdt a écrit :
>> [...]
> > > I'd argue that signaling this problem should be a checked exception.
> > > IMO this provides a clearer contract to the user.
> >
> > It doesn't. The user would have a false sense of security believing so.
> >
>
> I guess I disag
On 2021-06-27, Gilles Sadowski wrote:
> Hi.
>> [...]
>> it seemed Gilles was opposed to this idea
> Rather (IIRC) my last comment was that it was your choice as to
> what the API should look like.
Sorry, I didn't mean to misrepresent your POV.
> My opinion on the matter was along Gary's lines
On 2021-06-27, Gary Gregory wrote:
> Catching all unchecked exceptions (UE) and rethrowing as checked exceptions
> (CE) feels like both a horror show and an exercise in futility, especially
> in order to appease some tool that complains today of one thing which may
> complain differently tomorrow,
Perhaps the key point here is throwing a more specific exception than
RuntimeException? Even if it's a subclass of it. Adding the javadocs
for which exceptions are allowed to be thrown might be sufficient to
cover the DoS attacks.
On Sun, Jun 27, 2021 at 12:05 PM Torsten Curdt wrote:
>
> >
> > >
>
> > Based on that premise we could also just forget about checked exceptions
> > altogether.
>
> As Gary said (as Joshua Bloch said, as many people said), checked
> exceptions are for recoverable errors.
>
Maybe it boils down to the definition of "recoverable".
> Parsing an archive I personall
Checked exceptions are also used when the error isn’t a programmer error.
>From an aesthetic perspective, I prefer the unchecked exceptions unless an
API already established them. Subclassing IOException is fairly common for
example.
On Sun, Jun 27, 2021 at 10:37 Torsten Curdt wrote:
> > Can you
Hi.
Le dim. 27 juin 2021 à 17:37, Torsten Curdt a écrit :
>
> > Can you expand on that - I don't understand the horror or the futility.
>
> >
> > The futility is because it is wrong for the caller to expect that no
> > runtime exception can be thrown.
> >
>
> Based on that premise we could also j
> Can you expand on that - I don't understand the horror or the futility.
>
> The futility is because it is wrong for the caller to expect that no
> runtime exception can be thrown.
>
Based on that premise we could also just forget about checked exceptions
altogether.
I think the distinction is
On Sun, 27 Jun 2021 at 15:01, sebb wrote:
>
> On Sun, 27 Jun 2021 at 14:06, Torsten Curdt wrote:
> >
> > > feels like both a horror show and an exercise in futility
> >
> >
> > Can you expand on that - I don't understand the horror or the futility.
> >
> > It certainly is a bit of code smell - bu
Hi.
> [...]
> it seemed Gilles was opposed to this idea
Rather (IIRC) my last comment was that it was your choice as to
what the API should look like.
My opinion on the matter was along Gary's lines (which is J. Bloch's
rationale provided in "Effective Java").
Indeed I personally would indeed *n
On Sun, 27 Jun 2021 at 14:06, Torsten Curdt wrote:
>
> > feels like both a horror show and an exercise in futility
>
>
> Can you expand on that - I don't understand the horror or the futility.
>
> It certainly is a bit of code smell - but only because there is no quick
> way to harden the implemen
> feels like both a horror show and an exercise in futility
Can you expand on that - I don't understand the horror or the futility.
It certainly is a bit of code smell - but only because there is no quick
way to harden the implementations.
But I rather have a clear and stable API and fix the th
Catching all unchecked exceptions (UE) and rethrowing as checked exceptions
(CE) feels like both a horror show and an exercise in futility, especially
in order to appease some tool that complains today of one thing which may
complain differently tomorrow, I really don't like that idea on paper.
Le
+1 for 2)
In [Imaging] we do something similar, but it was easier because there were many
methods that were already doing it (throwing ImageReadException or
ImageWriteException).
Bruno
On Sunday, 27 June 2021, 11:03:31 pm NZST, Stefan Bodewig
wrote:
Hi
I'd like to get closure o
I personally think that we should look at it from the point of view of the
API consumer.
What would they want to happen in case of an error reading an archive?
IMO an IOException.
How we get to that exception on the implementation side is another matter.
If we could check all conditions and throw
Please have a look at the pack200 branch if you want, there are still
Javadoc TODOs but it's all there.
Gary
On Sat, Jun 12, 2021, 14:50 Stefan Bodewig wrote:
> On 2021-06-12, Stefan Bodewig wrote:
>
> > On 2021-06-12, Gary Gregory wrote:
>
> >> Please note that the Java 16 and 17 builds are no
On 2021-06-12, Stefan Bodewig wrote:
> On 2021-06-12, Gary Gregory wrote:
>> Please note that the Java 16 and 17 builds are now green on GitHub after my
>> changes this morning to update some dependencies.
> They haven't been green before - or for any JDK > 14 - because of
> missing pack200 clas
On 2021-06-12, Gary Gregory wrote:
> Please note that the Java 16 and 17 builds are now green on GitHub after my
> changes this morning to update some dependencies.
They haven't been green before - or for any JDK > 14 - because of
missing pack200 classes inside of the classlib.
Stefan
-
Hello.
Le lun. 7 juin 2021 à 06:51, Stefan Bodewig a écrit :
>
> On 2021-06-06, Gilles Sadowski wrote:
>
> > Le dim. 6 juin 2021 à 07:51, Stefan Bodewig a écrit :
>
> >> Hi
>
> >> I'm thinking about a specific IOException subclass that is thrown when a
> >> RuntimeException "happens" somewhere i
On 2021-06-06, Gilles Sadowski wrote:
> Le dim. 6 juin 2021 à 07:51, Stefan Bodewig a écrit :
>> Hi
>> I'm thinking about a specific IOException subclass that is thrown when a
>> RuntimeException "happens" somewhere in the code that parses data in
>> Zip/SevenZ/TarFile, see
> I'm afraid I miss
Ah, I see. These exceptions could derive from UncheckedIOException perhaps?
On Sun, 6 Jun 2021 at 15:56, Gilles Sadowski wrote:
>
> Le dim. 6 juin 2021 à 22:32, Matt Sicker a écrit :
> >
> > Well, if there's a parse error decompressing a file, that makes sense
> > as an IOException of some sort.
Le dim. 6 juin 2021 à 22:32, Matt Sicker a écrit :
>
> Well, if there's a parse error decompressing a file, that makes sense
> as an IOException of some sort.
The proposal is the change some unspecified RuntimeException
into an unspecified IOException.
My opinion is that a checked exception must
Well, if there's a parse error decompressing a file, that makes sense
as an IOException of some sort.
On Sun, 6 Jun 2021 at 12:01, Gilles Sadowski wrote:
>
> Le dim. 6 juin 2021 à 07:51, Stefan Bodewig a écrit :
> >
> > Hi
> >
> > I'm thinking about a specific IOException subclass that is thrown
Le dim. 6 juin 2021 à 07:51, Stefan Bodewig a écrit :
>
> Hi
>
> I'm thinking about a specific IOException subclass that is thrown when a
> RuntimeException "happens" somewhere in the code that parses data in
> Zip/SevenZ/TarFile, see
I'm afraid I missed part of the story as to what is the origin
+1 for the new option.
A fast fail for corrupted archive could help a lot.
Lee
On 6 5 2021, at 4:32, Gary Gregory wrote:
> In general, I think fail fast is ok with a clear exception message.
>
> Gary
> On Fri, Jun 4, 2021, 15:44 Stefan Bodewig wrote:
> > Hi all
> >
> > 7z archives provide CRCs f
Von: Gary Gregory
Gesendet: Friday, June 4, 2021 10:32:22 PM
An: Commons Developers List
Betreff: Re: [compress] 7z and Recovering Corrupt Archives
In general, I think fail fast is ok with a clear exception message.
Gary
On Fri, Jun 4, 2021, 15:44 Stefan Bodewig wrote:
> Hi all
>
> 7z
In general, I think fail fast is ok with a clear exception message.
Gary
On Fri, Jun 4, 2021, 15:44 Stefan Bodewig wrote:
> Hi all
>
> 7z archives provide CRCs for the metadata section so you can quickly
> identify a wide range of broken archives - which is far better than what
> you get for ZI
For the record: there is now a private mailing list fuzz-testing@commons
On Fri, 12 Mar 2021 at 14:00, sebb wrote:
>
> It might be possible to set up a dedicated mailing list just for these
> reports, privately archived.
> RMs could then be encouraged to check the list in the run-up to a
> releas
It might be possible to set up a dedicated mailing list just for these
reports, privately archived.
RMs could then be encouraged to check the list in the run-up to a
release (or they could subscribe).
If it turns out that the mail traffic is not too onerous, the mails
could be redirected to securi
If you don't want reports to get lost, but there is no suitable
mailing list, there is also the option to add multiple email addresses
(possibly private ones of individual contributors).
See https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary
for the details.
Changing the l
> > On Tue, Mar 9, 2021 at 11:16 PM sebb wrote:
> > >
> > > How often will the tool be run?
> > > How often does it need to be run?
> >
> > OSS-Fuzz runs its fuzzers continuously and will automatically pick up
> > new project commits. I don't know its precise schedule, but I expect
> > every proje
On Wed, 10 Mar 2021 at 07:13, Fabian Meumertzheim
wrote:
>
> On Tue, Mar 9, 2021 at 11:16 PM sebb wrote:
> >
> > How often will the tool be run?
> > How often does it need to be run?
>
> OSS-Fuzz runs its fuzzers continuously and will automatically pick up
> new project commits. I don't know its
On Tue, Mar 9, 2021 at 11:16 PM sebb wrote:
>
> How often will the tool be run?
> How often does it need to be run?
OSS-Fuzz runs its fuzzers continuously and will automatically pick up
new project commits. I don't know its precise schedule, but I expect
every project to be fuzzed at least a coup
How often will the tool be run?
How often does it need to be run?
On Tue, 9 Mar 2021 at 22:01, Matt Sicker wrote:
>
> Perhaps the output of this tool won't have nearly as much spam as
> Dependabot et al? If so, we could just use the security list.
>
> On Tue, 9 Mar 2021 at 15:48, sebb wrote:
> >
Perhaps the output of this tool won't have nearly as much spam as
Dependabot et al? If so, we could just use the security list.
On Tue, 9 Mar 2021 at 15:48, sebb wrote:
>
> On Tue, 9 Mar 2021 at 21:38, Gary Gregory wrote:
> >
> > What if we make the existing notification list private? Who uses t
On Tue, 9 Mar 2021 at 21:38, Gary Gregory wrote:
>
> What if we make the existing notification list private? Who uses that
> one and for what?
Not a good idea, as the contents are appropriate to developers not on the PMC.
> G
>
> On Tue, Mar 9, 2021 at 3:41 PM Torsten Curdt wrote:
> >
> > > At
What if we make the existing notification list private? Who uses that
one and for what?
G
On Tue, Mar 9, 2021 at 3:41 PM Torsten Curdt wrote:
>
> > At least for Compress I see value in Fuzz testing.
> > Any other opniions?
> >
>
> I totally see the value and it should go to a private list.
> At least for Compress I see value in Fuzz testing.
> Any other opniions?
>
I totally see the value and it should go to a private list.
On 2021-03-09, Gary Gregory wrote:
> A reminder that we can break our own builds by configuring maven plugins
> like spotbugs, pmd, and so on. If we need to configure another plugin to
> run in our builds to check for different errors, then let's consider that.
Fuzz testing need compute power bey
1 - 100 of 1247 matches
Mail list logo
