lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <200208060151.VAA23775@linus.mitre.org> From: coley at linus.mitre.org (Steven M. Christey) Subject: Re: it\'s all about timing choose.a.username@...hmail.com said: >What are the penalties now for not abiding by this guideline, or any >other guideline that might be out there. We explicitly stayed away from defining what the penalties are. That's outside the scope of the recommendations - the "marketplace" may decide, or perhaps, the legal community may decide. If there are no guidelines at all, then perhaps "the government" will decide (which obviously has its own issues, in an international community such as information security.) >Pretend that your (as in this) guideline was already implemented. How >on earth would you expect it to have stifled the release by both the >individual in (or a part of) SnoSoft and ISS. It at least establishes a point of discussion. Whether you agree with the particular points of the draft or not, they can be compared to the facts (or apparent facts) of the situation. For the ISS/Apache issue, it seems that nobody disputes that ISS gave Apache less than 7 days to respond to the initial report, before they published. This is not consistent with the spirit of the disclosure draft (I just took a look at it, and while it requires the vendor to respond within 7 days, it doesn't have a complementary suggestion that the reporter should give 7 days to the vendor! whoops). In the ISS/Apache case, we have the further complication that multiple vendors were involved (a difficult issue that is not addressed by the current draft, except in its recommendations for involving coordinators). Without community-defined guidelines, there are no clear boundaries to say whether ISS did things "reasonably" or not. The SnoSoft/HP issue is more complicated and not cleanly addressed by the disclosure draft, which does not cover accidental or unauthorized releases, and is not comprehensive on the role of third party coordinators. I think it demonstrates some of the complexity in vulnerability disclosure. Some people have argued that this means that there shouldn't be *any* guidelines, but I believe that we should try to be as detailed as possible in the guidelines to reduce confusion, provide flexibility where it is needed, and do what is possible to avoid regulations that may come from outside the IT community. - Steve
Powered by blists - more mailing lists