[FFmpeg-devel] [REQUEST] ffmpeg-security subscription

[Reimar Döffinger]

On 13.08.2019, at 09:45, Paul B Mahol <onemda at gmail.com> wrote:

> On Mon, Aug 12, 2019 at 6:15 PM Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> 
>> Hi Paul
>> 
>> On Mon, Aug 05, 2019 at 11:50:04AM +0200, Paul B Mahol wrote:
>>> Hi,
>>> 
>>> I here hereby request from lead FFmpeg entity to give me subscription to
>>> ffmpeg-security mailing list.
>> 
>> I am not sure who or what a "lead FFmpeg entity" is, But as iam being
>> highlighted
>> on IRC by you in relation to this, and as iam the most active developer on
>> security issues in ffmpeg it would be inpolite from me if i didnt say
>> something.
>> 
> 
> You are the only one working on this.

What is "this"? Michael is handling things coming in very quickly so there rarely is any need,
but I believe there are more people around with experience of handling reported issues.

>> About ffmpeg-security,
>> Theres currently no need for more manpower to handle security issues. We
>> have
>> a backlog of a few days of fuzzing issues only which is shrinking. And no
>> other
>> issues besides fuzzing issues. (part of the backlog probably was the
>> result
>> of distractions and some longer review cycles on some patches recently)
>> Also all patches are being posted in public so no access is needed for
>> reviews.
>> 
> 
> I strongly disagree. And I haven't asked if you need help.

Wait, is this about the fuzzing?
If so, I really disagree with throwing that in one pot with the handling of
security reports that might come with a polished exploit or even are active in the wild
(well, so far we've been lucky on that front to be spared that, but still).
Maybe people disagree, but I see the fuzzing as a development tool primarily,
and as such would probably consider quite different criteria applicable for access
compared to the security alias in general.
(which is again a different question from what wishes make sense to accomodate purely
from an effort point of view, but there might be a point that I believe Michael is the only one
with experience dealing with the fuzzer which is a non-optimal "single point of failure")

For non-fuzzing security issues, that usually is done on a pretty much need-to-know basis,
often based on who might be unavoidable to involve anyway, or who has access anyway.
Thus Michael's reply of not needing help is relevant - without a need the default response is likely
to involve people only on a case-by-case basis (generally, maintainers would and should be involved if the issue is related to their code).

That is my point of view at least, not sure if distinguishing fuzzing and other things is controversial.

Best regards,
Reimar Döffinger