On Wed, Mar 17, 2004, [EMAIL PROTECTED] wrote: > 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.
I'm not involved in security procedures anywhere, but my understanding is that when advising the clients/users might also risk advising potential attackers (as it would with most open source projects), you need to weigh up the gain of giving users early warning against giving attackers early warning. There's not many cases where you can warn only the 'good' users and not the bad unless you have a very tight relationship with a small customer base. In the case where you actually have a patch that fixes the problem, the users can apply it themselves if the developers don't. However, if your advisory is along the lines of "the entire design of your project is riddled with code that assumes $X and $X is incredibly vulnerable" then exploits will be developed quickly once the information is known, but fixes slowly. In that case, I would prefer as a user the situation where developers are advised without knowledge and I'm advised when fixes are available, to the alternative where I know straight away, so do attackers, and fixes aren't available for weeks. This all changes if exploits get out of course, and also changes in the case of uncooperative developers. -Mary -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
