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: <200208191935.PAA09673@linus.mitre.org> From: coley at linus.mitre.org (Steven M. Christey) Subject: (no subject) >as much as it is the $companies problem, it is also the users... as >they are using the software with the hole, and they must protect >themselves and their clients. And it's ultimately the users who can force vendors to become more responsive to vulnerability reports. I've heard several major vendors (not just one) say that the security community is a small part of their installation base, albeit a vocal one. Even the US government, while a major consumer, is a small portion of the overall market as I understand it. If the above paragraph has a grain of truth, then to me it seems that one challenge for those who want secure products, is to educate the general public to (1) ask their vendors for security (and *how* to ask for security), (2) monitor their vendors with respect to security, and (3) live with the fact that security by its nature may reduce some of the functionality. In the short term we have to live with (3), but good, solid research into "easy-to-use security" could help with that. But the question is, how can we get more "Joe Q. Customers" ask for security, and base their purchasing decisions on it (thereby affecting the vendors' bottom line)? And who is "we"? >By releasing the exploit it allows two things, > >1) Experience system administrators to devise temporary hacks to work >around the bug until it is properly fixed. One difficulty here is when the only "temporary hack" is to completely disable the service. If you've got a service that's meant for complete access to the Internet or some other set of non-trusted computers (say, a web or mail server), you don't necessarily have a lot of options. It seems reasonable to give the vendor *some* opportunity to fix the issue before releasing a fully functioning exploit, not for the sake of the vendor, but for the sake of most admins. - Steve
Powered by blists - more mailing lists