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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ