Hi (Fabian)
by now we've resolved the first issues detected by ClusterFuzz (and I
forgot to credit it OSS Fuzz in Compress, my bad). What we observed is
that the issues became public automatically once the patch fixing the
issue was merged into master and ClusterFuzz reran the test. In the case
of Compress somewhere around 24 hours after fixing things in master.
So far none of the issues we resolved would be deemed as a security
issue. But now we wonder, what if something indeed was a security issue
that we do not want to become public knowledge before we have cut a
release? Is there a way to prevent a verified and fixed issue from
becoming public automatically?
Here at the ASF we vote on releases, and we vote on the code base in our
default branch (master for most if not all components). Voting takes at
least three days, so the current behavior would mean the issue became
public knowledge a few days before a release fixing it was available.
Can you shed any light on this?
Thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
