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