Re: How to deal with reporters who don't want their bugs fixed?

[Solar Designer <solar () openwall com>]

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