Brian Lloyd wrote:
...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. Other recommendations: - 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? --Richard