...or will decide that doing so is unreasonable and use something else instead :( Note that I'm not necessarily criticizing that particular policy, just pointing out that _any_ policy will have some upside and some downside. The challenge will be coming to agreement on a policy with the right balance that everyone can live with.
How about something along the lines of:
- Development team only disclosure for the first x days (2 to 7 days is the maximum here I would think), in order to develop a workaround/patch.
- Full disclosure after that, along with a published patch, hotfix or workaround.
- Increase the number of people who have access to the security section of the collector, to increase the chance that it will be discussed.
- Form a closed security list for discussing such things amongst selected developers, away from the general public gaze (does such a thing already exist?)
At some stage the sysadmin has to take responsibility for the packages they are using. I tend to believe, as almost certainly most of the security community does, that not all crackers are just script-kiddies waiting for an exploit. Lets face facts -- if someone is reporting an exploitable hole, anyone else (white/black/grey hat) could have also found it.
I for one would love to know things like:
Jamie Heilman wrote: >Clemens Robbenhaar wrote: >> malicious Python Scripts on my site (I guess , and I do not use >> DTML >> or some Tree-stuff -- thus I did not upgrade yet, and You may feel >> free
>Actually... unless you've altered the ZMI and HelpSys, you do use >dtml-tree ...and HelpSys is publically traversable by default.
Anyone else spot the irony in the situation that _all_ the available security holes are available to a user who cracks the Zope collector site?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce