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: <200208022302.TAA27411@slartibartfast.magrathea.com> From: ras at slartibartfast.magrathea.com (Robert A. Seace) Subject: Re: it\'s all about timing In the profound words of Steven M. Christey: > [snip...] > If there is enough awareness of disclosure issues in the IT community, > then hopefully this won't happen as much. However, as you say, there > will always be people who won't follow the disclosure guidelines. > > You may be surprised to learn that the RVDP draft specifically tells > vendors that they should be prepared for such a situation: > > 3.3.1 Vendor Responsibilities > > 7) The Vendor SHOULD recognize that inexperienced or malicious > reporters may not use proper notification, and define its own > procedures for handling such cases. Why must they automatically be labelled either "inexperienced" or "malicious", if they don't choose to follow the chosen guidelines?? Suppose they simply disagree with those guidelines? They may feel it's not THEIR job to spend a large portion of their time trying to educate the vendor about their own broken software... They may feel they have no obligations in that area, at all... They may simply be releasing the information to the public out of pure good will, when they could have instead simply kept it to themselves, leaving everyone still at risk to the issue, and completely ignorant of it... Surely you wouldn't think THAT is a preferable situation to informing the public without prior vendor notification? Because, if you start throwing such labels around, that's precisely what such people will do... And, *I*, for one, really would prefer to be informed, rather than remain in the dark; and, to hell with the software vendor! At least if I know about a problem, I can take steps to protect myself, even if the vendor can't/won't... So, if you're still modifying this "policy", I would really suggest changing that language... Just drop the whole labelling of such people, and simply say something like, "Some reporters may not follow these guidelines for notification."... No judging them or their reasons for doing so... Not everyone is going to agree with you, no matter WHAT you come up with; and, negatively labelling all those who don't agree is really not very nice, and in this case, would be highly counter-productive, I think... Basically, I don't think any bug-reporter should EVER be attacked, no matter what policy they followed (if any)... Remember, they are doing this on their own time... They don't have to tell anyone at all... Be thankful they are telling the public at all, rather than bitch about HOW they choose to do so... (Yes, yes, I think most people will agree it would be BEST to do things a certain way... And, that would be really NICE if everyone did that... But, it shouldn't be any kind of requirement, where everyone who doesn't do it is an instant asshole... Not everyone always has time/desire/whatever to be the nicest and most polite they possibly can be... And, we shouldn't go around trying to codify exactly HOW nice and polite everyone MUST be...) -- ||========================================================================|| || Rob Seace || URL || ras@...rathea.com || || AKA: Agrajag || http://www.magrathea.com/~ras/ || rob@...dstock.com || ||========================================================================|| "Can we drop your ego for a moment? This is important." "If there's anything more important than my ego around, I want it caught and shot now." - THGTTG
Powered by blists - more mailing lists