Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Jan 2018 16:38:41 -0500
From: "Luedtke, Nicholas (Cyber Security)" <nicholas.luedtke@....com>
To: oss-security@...ts.openwall.com
Subject: Re: How to deal with reporters who don't want their
 bugs fixed?


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. 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.

--Nicholas Luedtke HPE Cyber Security




Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ