Date: Thu, 18 Jan 2018 23:01:24 +0100 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: How to deal with reporters who don't want their bugs fixed? On Thu, Jan 18, 2018 at 04:38:41PM -0500, Luedtke, Nicholas (Cyber Security) wrote: > On 1/18/2018 4:21 PM, Solar Designer wrote: > >I think it's best for your project (I guess glibc?) to prominently > >publish near the security contact address a maximum embargo time you'd > >(be likely to) agree to. That's what security at kernel.org does > >(7 days) and what we do with (linux-)distros (14 days). That way, it's > >less important for you to judge whether the reason for embargo is > >valid/altruistic or bogus/selfish - a sane maximum embargo time > >minimizes the damage to all parties either way. When someone requests a > >longer embargo for whatever reason, just decline and insist on your > >previously published maximum. Those who want to have their issue > >disclosure timed with some other event will then be expected to delay > >reporting the issue to your project until it's close enough to that > >other event. That's not ideal, but I think it's better than having no > >maximum embargo time specified. > > I generally agree with this, but it also creates the risk that reporters > will simply wait till the maximum time frame fits within their desired > reporting time. Which of course delays the reporting of the bug to the > vendor/project. That's precisely what I wrote above, and I think it's not as bad as the original situation Florian described. The project gets less time, but does it need more time when it can't release a fix anyway? The reduced exposure - even if to people and infrastructure of the project itself - reduces risk of leaks. Terms like this will also serve as a reminder to the reporter that they're indeed being selfish and would have wanted an unreasonably long embargo. Some, but not all, will change their mind. > What I have seen in the past is a negotiated partial > disclosure where the patch is released with minimum details with the > line that says "Full details with be released by XXX at YYY conference." > That way if ego is the factor then the reporter also gets a slight > teaser for his/her talk. Of course one could just use the patch to get > the details depending on the issue. I think "semi-public" is the worst state an issue can be in, making the above suggestion the worst of those mentioned in this thread so far. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ