full-disclosure - Re: it\'s all about timing

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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