Re: [PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Carlos O'Donell <carlos@redhat.com>]

On 10/14/26 12:16 PM, Siddhesh Poyarekar wrote:
> n 10/14/26 11:12 AM, Tom Tromey wrote:
>>>>>>> Siddhesh Poyarekar <sipoyare@redhat.com> writes:
>>> On 10/12/26 9:49 AM, Andrew Burgess wrote:
>>>> 3. The real change: clearly state that bugs in the DWARF/BFD parser
>>>> can be security bugs, but they are unlikely to be considered high 
>>>> priority, and users should instead use sandboxing to provide 
>>>> protection.  The text about bugs from well-formed programs is retained.
>> 
>>> I don't have a strong opinion on the meat of the change, but I want
>>> to point out that this is not sufficient deterrence for people
>>> flooding the project with such reports to get CVE creds in their
>>> name.  What priority a CVE gets downstream is typically a result of
>>> perception and the relatively dumb CVSS scores.  Unfortunately all
>>> major distributions are currently lost to that madness and
>>> "unlikely to be considered high priority" may not actually pan out
>>> that way in practice.
>> 
>> I agree but we can only control gdb, not what other projects do.
>> That is, I think that CVEs are gamed dishonestly nowadays, but it's
>> not clear to me what other options we have for dealing with this.
> The glibc CNA plans to onboard the binutils project to the CNA
> program so that we can handle those and stem the CVE gaming for the
> project.  We could extend that to gdb too if there's interest, but we
> will need volunteers from the gdb team on the security team because
> the gdb security policy is a bit more complex to interpret than the
> binutils one, which assumes that all input as trusted.

I'm happy to offer mentorship and training for anyone from the gdb
community that wants to join the security team.

It would help us better document onboarding and review policies :-) 
> Of course, we'd still need the policy to define what can be
> reasonably secured and exclude the rest from scope.

Agreed.

-- 
Cheers,
Carlos.