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

[Gynvael Coldwind <gynvael () coldwind pl>]

Hi there,

Speaking for myself from a security researcher's perspective, I would say
it depends on the reason for embargo, and what ends up protecting users
better.

There might be valid reasons for embargoes - one example (but not the only
one) is when a given bug affects multiple similar products, and a
disclosure on the side of one product would 0-day users using other
products. It sounds logical to wait until fixes are available before
disclosure (keeping in mind at the same time that a certain sane deadline
must be met too).

On the other hand there are reasons for embargoes which I don't find valid,
where the examples you've given ("paper/conference presentation/patent
submission") fall into this category.
They don't sound as something that would benefit users' security (please
correct me if I'm wrong) and I'm not a big fan of sitting on already
discovered unpatched security bugs (in the end bug discovery might be a
function of time for all we know).

In this case I would consider explaining this to the researcher and
proceeding with patching.
In the end if this causes a given person to report a known-to-them bug just
before a conference/etc it changes little vs. actually waiting for the
proposed just-before-conference/etc deadline anyway (if accepting the
embargo agreement that is).

Cheers,
Gynvael

On Thu, Jan 18, 2018 at 5:11 PM Florian Weimer <fweimer () redhat com> wrote:

> Subject says it all: What do you do if you receive a vulnerability
> report, and the reporter requests an embargo at some time in the future
> because that's when their paper/conference presentation/patent
> submission is scheduled?
>
> The obvious approach is to find a prior public report of essentially the
> same bug and fix that (which will work surprisingly often), but let's
> assume that this isn't the case.
>
> Thanks,
> Florian