No worries, I'm also not in a rush to change anything, so we can give this
discussion the space and time it deserves. If you want me to weigh in on
any issue you open on GitHub, just @fmeum.

An additional argument in favor of a delayed publication could be that
sometimes completely unrelated upstream changes end up "fixing" a security
issue: The original testcase triggering that issue in OSS-Fuzz no longer
does so. But since the root cause hasn't been fixed, letting the fuzzer run
for a couple of minutes with the now public testcase will reproduce the
original security issue. Of course, someone who goes to those lengths could
just run the fuzzers themselves, so the actual impact of that situation is
not clear.


On Sun, May 9, 2021 at 8:54 PM Stefan Bodewig <[email protected]> wrote:

> Many thanks Fabian
>
> and sorry for the delay - unfortunately I'm not really able to free up
> as much time as necessary for any OSS stuff right now
>
> On 2021-05-03, Fabian Meumertzheim wrote:
>
> > The behavior you are observing has only become the standard somewhat
> > recently [1], which is also why I had decided to point it out before we
> > performed the integration [2].
>
> > [1] https://github.com/google/oss-fuzz/issues/5255
>
> I must have overlooked that back then - or just didn't understand what
> it meant. One key is the phrase "after a patch is released" which also
> is used in [1] which means a completely different thing to ASF
> communities than to the person opening the issue above. Nobody around
> here would argue against disclosing details of a vulnerability after a
> new release containing the fix is available.
>
> The best we can do probably is pointing out that the new policy is
> incompatible with the ASF security policy - point 14 in
>
> https://www.apache.org/security/committers.html#vulnerability-handling
>
> without trying to argue who is right. Going from there we will see
> whether there is an option for ASF projects to continue using OSS Fuzz
> or not. Unfortunately I believe this discussion must be driven by
> somebody with a predictable and sufficiently large slice of time for
> this, which I will not be for at least the next week, likely longer.
>
> Unless anybody else jumps in I'll take it on myself once I believe to be
> available. Fortunately so far no issues have shown up that would force
> ou hand - and even if something came up I'm sure we could figure out
> some sort of singular exemption.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to