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 23:01:24 +0100
From: Solar Designer <>
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 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.


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