Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAnPYQ4Ck7uzf7FFOJX-H1GDOtnHDbXyZ_mzYztSK8O6DF4y7Q@mail.gmail.com>
Date: Thu, 18 Jan 2018 17:06:04 +0000
From: Gynvael Coldwind <gynvael@...dwind.pl>
To: oss-security@...ts.openwall.com
Subject: Re: How to deal with reporters who don't want their
 bugs fixed?

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

Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.