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>] [day] [month] [year] [list]
Message-ID: <200208030035.g730ZWI12077@mailserver4.hushmail.com>
From: choose.a.username at hushmail.com (choose.a.username@...hmail.com)
Subject: Re: it\'s all about timing

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I keep re-reading this and all I get out of it is, the vendor is doing the customer an enormous favor by allowing them to report a problem with their product.

Why does this stick in my throat?

"it will be easier for people to report vulnerabilities to them"

Is that so? Who is doing who the favor. Someone who spends hundereds of dollars or thousands of dollars and finds a problem in that vendors product. Or the vendor for allowing you, the customer, to buy their product? You should be honored by giving your hard earned money to me the vendor. Here take my product and tough shit if it doesn't work well.

How about fuck the vendor. Find a bug, post away 0-day? Or give me money back for the defective product you sold me plus compensation for the time and effort it took me to fix the problems your software did on my machine.


>In the meantime, the current RVDP draft already has a number of
>suggestions for vendors:
>
>3.3.1 Vendor Responsibilities
>
>   1) The Vendor MUST make it as easy as possible for Reporters,
>   Coordinators, Customers, and the Security Community to notify the
>   Vendor of vulnerabilities.
>
>as well as:
>
>   3) The Vendor SHOULD ensure that its staff knows how to recognize a
>   reported security issue and direct it to the Security Response
>   Capability.  This recommendation applies to staff who provide support
>   online, over the telephone, in person, or through some other means by
>   which reporters may interact with the Vendor.
>
>as well as:
>
>   6) The Vendor MUST provide a facility for individuals or
>   organizations who are not Customers to report vulnerabilities.  The
>   Vendor SHOULD NOT require (1) an active technical support number, (2)
>   telephone access that is not toll-free, or (3) user registration for
>   a web site or other facility that would be used for reporting.
>
>
>If more vendors follow the recommendations in the current draft, it
>will be easier for people to report vulnerabilities to them, which I
>think is a good thing.
>
>
>>Or do you mean the one-off vulnerabilty report, the one that some
>>individiual stumbles upon and sends it off to the lists.
>
>If the one-off person knows about security-related mailing lists, then
>hopefully they'll know something of disclosure issues.
>
>>Are you trying to harness them? Do you think some standard setout on
>>what do do with the reporting is going to trickle down to the
>>individual man in the street and he's going to (a) know about it (b)
>>be bothered to follow the method if he did.
>
>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.
>
>
>I've mentioned at least 4 vendor requirements from the current draft,
>which would make the notification process easier for researchers.
>
>>Is there then a third set out there that needs this guidence everyone
>>is hollering about?
>
>I think so, and that's the people who are somewhere in between - maybe
>they're not professionals, but maybe they like to do research for fun,
>to analyze the software they use themselves, to build a resume,
>whatever (and before someone misinterprets what I just said, I
>personally don't think that there's anything wrong with doing research
>for resume-building).  Sometimes, it seems that researchers start out
>by releasing advisories without notifying the vendor, then as they
>gain experience, they work with the vendor more and more.  But I don't
>have any hard numbers to back that up.  Indeed, the whole area of
>disclosure is woefully short of hard numbers.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@...ts.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1LJFUfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkB3kAKCoupjU2QzSO75H6CKBD4l/pMwQ2wCgsanIKDniM8Xr+GII5T7VWdS8
4i8=
=esAQ
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ