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?


Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to