Insecurity people panic... security people take action... Security people that ban a program that finds/exploits a hole are not security people... security people makes sure a well known a very impacting vulnerabiliy is taken away.
I think that letting users to know that e.g. their Bank's website SSL key is broken is a good thing, they will avoid using and start complaining (As I did, now my bank uses a secure key, haven't I proven the key I might have been using for longer). The doctrine of not making people aware of vulnerabilities is a botched one. The point is: Bad people will know about the vulnerability. Having good people not knowing, makes them unable to take action so the result is vulnerability. It's wrong to blame who finds a problem for it... On Wed, Aug 6, 2008 at 1:49 PM, Andrew Hood <[EMAIL PROTECTED]> wrote: > Sake Blok wrote: > >> May I have your votes please? ;-) >> >> 1) Don't include the code at all > > There are enough weak key identifiers out there without burdening > Wireshark with a CPU intensive test for a one off problem. The next time > someone finds a weakness it is bound to be a different problem needing > different discovery. > > I don't want to have anyone in our networks using a version of Wireshark > with the ability to crack keys. It will panic the security people and > they will ban Wireshark totally. Wireshark it too useful to let that happen. > > -- > There's no point in being grown up if you can't be childish sometimes. > -- Dr. Who > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > https://wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
