Date: Sat, 27 Jan 2018 10:02:03 -0500 From: Stiepan <stie@....swiss> To: oss-security@...ts.openwall.com Subject: Re: How to deal with reporters who don't want their bugs fixed? I will try responding to both here: well, however flawed it might be and oftentimes is in practice, there is the universal Hyppocrate's oath in the case of medicine and it sort of works. That is what I meant, using possibly inadequate words. If boilerplate agreement sounds better than an universal code of ethics for our profession (and I think this is attainable, not "universal ethics" taken out of context, making it an oxymoron), as long as the effects are with it, I don't think that wording should be the main issue at hand. As for the register's article, it gives this image - https://www.theregister.co.uk/Design/graphics/icons/404_img.jpg - in guise of a 404 error, so I cannot make a proper opinion for the moment. Without reading it though, I cannot but see the parallel between Intel deactivating some CPU feature to make it secure and surgical ablation! There are (less mediatized) precedents of the like: see for instance how Apple had to remove Apple Pay history in a rush because it exposed an otherwise (provably?) secure enclave. What I do see in common here is that the end user's interests were sacrificed and some sold feature removed, to remedy a design flaw affecting the security of their information. If you remove the ICT Security professional glasses and take the more generic context of planned obsolescence into account, this becomes very interesting, and there are quite a few other examples of the like. Hence, a need probably arises to have an oath for ICT in general and not security in particular, sec. being what surgery is to general medicine, when not done preventively / by design, as we (CEuniX.world) and hopefully others are making every effort to do, instead of the "accept defeat" approach we hear so often from many vendors and even certification bodies, which is itself a reason to begin worrying about the status quo. -------- Mensaje original -------- On 26 ene. 2018 18:48, Mikhail Utin escribió: > I 100% agree with Solar's response. We should not limit our freedom to choose how we will handle our intellectual property. That is how I read the original statements below. > > Not to cause more discussion, but here is the example of how "universal ethics" work: > > https://www.theregister.co.uk/2018/01/25/intel_spectre_disclosed_flaws_november/ > > Mikhail Utin, CISSP > > ________________________________ > From: Solar Designer > Sent: Friday, January 26, 2018 12:16 > To: oss-security@...ts.openwall.com > Subject: Re: [oss-security] How to deal with reporters who don't want their bugs fixed? > > On Fri, Jan 26, 2018 at 10:23:49AM -0500, Stiepan wrote: >> I think that clear rules might be welcome: > > I agree (specifically, I had suggested explicit maximum embargo times), > but such rules must not be one and only industry standard. Anyone or > any project may propose rules, and other projects are welcome to reuse > those rules, but they must not have to - they could as well use > different rules, or none. At best, a relatively non-controversial > and brief boilerplate could end up being reused by many projects. > >> We as a profession should have a clear code of ethics > > No. Let's not use the word ethics. That word, except when explicitly > referring to a particular person's or group's ethics, implies that when > we (dis)agree or are judging others, we claim to be necessarily right - > but in reality we're necessarily subjective. > > This would be just as flawed a concept/term as "responsible disclosure". > (I refrain from using that term as well, except when pointing out just > how unnecessarily judgemental it is - implying that other kinds of > disclosure would have been "irresponsible" - but we're subjective.) > >> universal ethics' code > > That's an oxymoron. No such thing can possibly exist. > > Alexander @openwall.com>
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