Mary, I don't know about good etiquette, but if the product is open source, you still advise the user there is a bug, and advise them you will be releasing the security problem to the developers web site for them to recitify the problem. The key issue is that both the developers and the client needs to know about the problem. So they both can make an "educated" decission on their course of action.
You would not be blatent enough to say I have checked this hole on microsoft.com who uses version 4.09rc1 of xyz which has sql injections problems. I think you need to use a bit of smarts and just say Version 4.09rc1 of xyz has sql injection issues which results in blah. Then again it depends on your ethics, and how much moral fiber you and the exposed company has. ;-) There was a case 2 years ago about some developer who worked for a web company he found huge gaping security holes in their applications advised the bosses who sacked him, in turn released the security holes to the general public in a bugtraq list. He was taken to court and sued by the company mind you that was in the good ole US of A. I don't know how the court case ended. I hope the ex-employee won. On Wed, Mar 17, 2004, [EMAIL PROTECTED] wrote: > If the bug is in an opensource web app post it to the app's bugzilla > list to resolve it. ;-) Is this good etiquette in the case of serious security breaches? It potentially alerts the entire web-using world to the existence of the problem. If the fix is difficult or complex, this potentially allows exploits to be developed before fixes, which is what you try and avoid when you're reporting a security problem. I would tend to leave the decision to the developers about whether to post the bug in any publicly accessible place. Of course, the real problem is when the developers are unresponsive. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
