Re: [Zope-dev] tortoise v. hare (was: BTrees strangeness)
Chris McDonough wrote: > I've looked at that issue many times during various bug days and it > sounded reasonable enough but it always seemed like slightly > higher-hanging fruit than other issues because it introduces new > features as well as fixes bugs. Oh granted, it totally is. It just happens to be high hanging fruit I have a vested interest in, and don't mind squeeking about once a year. Now I've done my squeeking, so I'm good till '05. > Personally I prefer that someone who wants to introduce new features > (even small ones, like API additions) into the core do it via their own > committer privileges and thus sign up to maintain it for the rest of Yeah well... we've been over that before, I refuse to sign that agreement. If that means my patches go ignored for eternity, so be it, but it really seems like ZC is just cutting of their nose to spite their face. > The reason I think people don't jump on collector issues like this > one is because of the natural "he who touched it last owns it" > policy of the core code. I own enough of Zope 2 core code to make > me uncomfortable at this point; owning more just isn't very > attractive to me unless the upside is very up. Thats an unfortunate situation to be sure, I don't have any solutions to offer as its not a technical issue. All I can say is that we know the code doesn't care who touched it last, its going to break or work regardless. The sooner the community accepts that, the sooner we can get out of the rut and make some more progress. > Straightforward obvious bugfix patches with limited scopes are another > matter; those usually get applied first during bug days. This is also > why "geddons" are attractive; they focus effort on an isomorphic class > of bugs without requring that the fixer wade through proposals for > features, API improvements, and provides an effective loophole for "he > who touched it last" problem. Sure, I have nothing against geddons per se[1], but they just won't fix every class of problem. One of the advantages of OOP is being able to focus on a component of the larger system, replace it, and see how the system around it reacts. The clearly defined component boundries are a big advantage to that kind of development strategy, its a great way to make localized behavioral changes. I don't think any amount of geddon activity would solve the problems I've faced with the current result caching API. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly [1] I'd love to see the DTML namespace qualification (see bug 1217) geddon occur, if for no other reason than to watch the resulting code-bloat totally school some of the "dtml uber alles" hold outs. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] tortoise v. hare (was: BTrees strangeness)
Tres Seaver wrote: > > We should have a 'hasattr-geddon' and remove every trace of that > monstrosity from Zope and the CMF; likewise a 'bareexcept-geddon' > (there might be a few places which are smart enough to do 'except:', but > I doubt it). Now its not a geddon by any means, but the code I wrote and offered in bug 911 fixes 3 (iirc) bare excepts, a couple of privacy holes, several bugs, and adds some enhancements that my tests have shown are basically backwards compatible with everything out there (though I didn't realize at the time CMF had a cache manager of its own and I'm not sure how they interact). Its been a year now since I offered that code and I haven't gotten so much as a comment on it. Maybe its time to wander over and give it a look? -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Announce: Reusable Zope Public License 2.1
[EMAIL PROTECTED] wrote: > The 5th is confusing. What's the situation with *BSD like ports where > the source code is patched right before compiling? What is the "date of > change" in that case? In that case the ZPL'd program isn't being redistributed modified, so the 5th clause doesn't apply. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Collector] Strange reject policy
Ken Manheimer wrote: > > All the actions are verbs, "won't fix" is not a verb. How about 'bikeshed' ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion
Chris Withers wrote: > I suppose it's still one step up from CVS where you have to specify > the binary-ness of each file you upload rather than being able to > put a mapping i na config file... CVSROOT/cvswrappers ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] patch for #1074
As per usual the collector won't let me attach patches to issues I
didn't start, so here's the patch for some issues discussed surrounding
1074. Now there are some caveats to this patch... I haven't protected
every method, left to do yet are: manage_FTPget, get_size/getSize
Also note this patch removes dependance on MessageDialog - that really
had no bearing on the issue at hand and I only include that portion of
the patch because in my fork I removed all reliance upon MessageDialog
(a class I really loathed) and I'm too lazy to add it back for the
purposes of this patch.
--
Jamie Heilman http://audible.transient.net/~jamie/
"You came all this way, without saying squat, and now you're trying
to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
I liked you better when you weren't saying squat kid." -Buddy
--- PythonScript.py 22 Mar 2004 16:26:52 - 1.56
+++ PythonScript.py 1 May 2004 21:42:49 -
@@ -16,11 +16,10 @@
This product provides support for Script objects containing restricted
Python code.
"""
-
__version__='$Revision: 1.56 $'[11:-2]
import sys, os, traceback, re, marshal, new
-from Globals import DTMLFile, MessageDialog, package_home
+from Globals import DTMLFile, package_home
import AccessControl, OFS, RestrictedPython
from Acquisition import aq_parent
from OFS.SimpleItem import SimpleItem
@@ -29,11 +28,11 @@
from webdav.Lockable import ResourceLockedError
from webdav.WriteLockInterface import WriteLockInterface
from Shared.DC.Scripts.Script import Script, BindingsUI, defaultBindings
-from AccessControl import getSecurityManager
+from AccessControl import getSecurityManager, Permissions
from OFS.History import Historical, html_diff
from OFS.Cache import Cacheable
from AccessControl.ZopeGuards import get_safe_globals, guarded_getattr
-from zLOG import LOG, ERROR, INFO, PROBLEM
+from zLOG import LOG, ERROR, INFO
from zExceptions import Forbidden
import Globals
@@ -42,6 +41,11 @@
Python_magic = imp.get_magic()
del imp
+VIEW_PERM = Permissions.view
+MANAGE_PERM = Permissions.view_management_screens
+CHANGE_PERM = Permissions.change_python_scripts
+PROXY_PERM = Permissions.change_proxy_roles
+
# This should only be incremented to force recompilation.
Script_magic = 3
_log_complaint = (
@@ -81,6 +85,8 @@
The function may include standard python code, so long as it does
not attempt to use the "exec" statement or certain restricted builtins.
"""
+security = AccessControl.ClassSecurityInfo()
+security.declareObjectProtected(VIEW_PERM)
__implements__ = (WriteLockInterface,)
meta_type='Script (Python)'
@@ -109,24 +115,20 @@
self.ZBindings_edit(defaultBindings)
self._makeFunction()
-security = AccessControl.ClassSecurityInfo()
-
-security.declareObjectProtected('View')
-security.declareProtected('View', '__call__')
-
-security.declareProtected('View management screens',
- 'ZPythonScriptHTML_editForm', 'manage_main', 'read',
- 'ZScriptHTML_tryForm', 'PrincipiaSearchSource',
- 'document_src', 'params', 'body', 'get_filepath')
+security.declareProtected(VIEW_PERM, "__call__")
+security.declareProtected(MANAGE_PERM, "ZScriptHTML_tryForm")
+security.declareProtected(CHANGE_PERM, "manage_historyCopy")
+security.declareProtected(CHANGE_PERM, "manage_beforeHistoryCopy")
+security.declareProtected(CHANGE_PERM, "manage_afterHistoryCopy")
+security.declareProtected(MANAGE_PERM, "manage_main",
+ "ZPythonScriptHTML_editForm")
ZPythonScriptHTML_editForm = DTMLFile('www/pyScriptEdit', globals())
manage = manage_main = ZPythonScriptHTML_editForm
ZPythonScriptHTML_editForm._setName('ZPythonScriptHTML_editForm')
-security.declareProtected('Change Python Scripts',
- 'ZPythonScriptHTML_editAction',
- 'ZPythonScript_setTitle', 'ZPythonScript_edit',
- 'ZPythonScriptHTML_upload', 'ZPythonScriptHTML_changePrefs')
+
+security.declareProtected(CHANGE_PERM, "ZPythonScriptHTML_editAction")
def ZPythonScriptHTML_editAction(self, REQUEST, title, params, body):
"""Change the script's main parameters."""
self.ZPythonScript_setTitle(title)
@@ -135,12 +137,14 @@
return self.ZPythonScriptHTML_editForm(self, REQUEST,
manage_tabs_message=message)
+security.declareProtected(CHANGE_PERM, "ZPythonScript_setTitle")
def ZPythonScript_setTitle(self, title):
Re: [Zope-dev] Re: Policy for Collector-Issues 545 and 1217?
here's the patch I'd have attached to http://zope.org/Collectors/Zope/1217 if the collector could collect -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby --- lib/python/App/dtml/manage.dtml 22 Dec 2002 17:53:57 - 1.10 +++ lib/python/App/dtml/manage.dtml 27 Apr 2004 21:14:33 - @@ -19,14 +19,14 @@ - - - --- lib/python/App/dtml/manage_tabs.dtml4 Nov 2003 16:52:24 - 1.14 +++ lib/python/App/dtml/manage_tabs.dtml27 Apr 2004 21:14:33 - @@ -59,7 +59,7 @@ align="center"> href="&dtml-action;"href="&dtml-URL1;"href="" target="&dtml-target;"> @@ -68,7 +68,7 @@ align="center"> href="&dtml-action;"href="&dtml-URL1;"href="" target="&dtml-target;"> --- lib/python/OFS/dtml/fileEdit.dtml 6 Jul 2003 10:43:53 - 1.9 +++ lib/python/OFS/dtml/fileEdit.dtml 27 Apr 2004 21:14:33 - @@ -10,7 +10,7 @@ text type and small enough to be edited in a text area. - +" method="post" enctype="multipart/form-data"> --- lib/python/OFS/dtml/findFrame.dtml 22 Dec 2002 17:53:59 - 1.3 +++ lib/python/OFS/dtml/findFrame.dtml 27 Apr 2004 21:14:33 - @@ -5,12 +5,12 @@ - /manage_findAdv" NAME="findForm" - /manage_findForm" NAME="findForm" MARGINWIDTH="2" MARGINHEIGHT="2" SCROLLING="auto"> - /manage_findResult" NAME="findResult" MARGINWIDTH="2" MARGINHEIGHT="0" SCROLLING="auto"> --- lib/python/OFS/dtml/findResult.dtml 19 Jan 2004 19:56:52 - 1.6 +++ lib/python/OFS/dtml/findResult.dtml 27 Apr 2004 21:14:34 - @@ -60,13 +60,13 @@ - < Previous + &dtml-sequence-query;query_start=&dtml-previous-sequence-start-number;">< Previous - Next > + &dtml-sequence-query;query_start=&dtml-next-sequence-start-number;">Next > --- lib/python/OFS/dtml/history.dtml22 Dec 2002 17:53:59 - 1.4 +++ lib/python/OFS/dtml/history.dtml27 Apr 2004 21:14:34 - @@ -2,7 +2,7 @@ - + " method="POST"> @@ -10,7 +10,7 @@ -< Later Revisions +?first_transaction:int=&dtml.-next;&last_transaction:int=&dtml.-first_transaction;&HistoryBatchSize:int=&dtml.-HistoryBatchSize;">< Later Revisions @@ -21,7 +21,7 @@ -Earlier Revisions > +?first_transaction:int=&dtml.-last_transaction;&last_transaction:int=&dtml.-last;&HistoryBatchSize:int=&dtml.-HistoryBatchSize;">Earlier Revisions > --- lib/python/OFS/dtml/main.dtml 19 Jan 2004 19:56:52 - 1.22 +++ lib/python/OFS/dtml/main.dtml 27 Apr 2004 21:14:34 - @@ -34,10 +34,10 @@ - + /" method="get"> 1"> + onChange="location.href='/'+this.options[this.selectedIndex].value"> Select type to add... &dtml-name; @@ -57,7 +57,7 @@ - +/" name="objectItems" method="post"> --- lib/python/OFS/dtml/properties.dtml 16 Jan 2004 15:35:13 - 1.16 +++ lib/python/OFS/dtml/properties.dtml 27 Apr 2004 21:14:34 - @@ -31,7 +31,7 @@ - +" method="post"> Properties allow you to assign simple values to Zope objects. To change @@ -223,7 +223,7 @@ - +/manage_addProperty" method="post"> To add a new property, enter a name, type and value for the new --- lib/python/OFS/dtml/propertyType.dtml 22 Dec 2002 17:53:59 - 1.3 +++ lib/python/OFS/dtml/propertyType.dtml 27 Apr 2004 21:14:35 - @@ -26,7 +26,7 @@ - +" method="POST"> To change property names and values, edit them and click --- lib/python/OFS/dtml/propertysheets.dtml 29 Sep 2003 12:16:37 - 1.4 +++ lib/python/OFS/dtml/propertysheets.dtml 27 Apr 2004 21:14:35 - @@ -1,7 +1,7 @@ - +" method="post"> --- lib/python/OFS/dtml/renameForm.dtml 22 Dec 2002 17:53:59 - 1.5 +++ lib/python/OFS/dtml/renameForm.dtml 27 Apr 2004 21:14:35 - @@ -7,7 +7,7 @@ )"> - +" method="post"> ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Policy for Collector-Issues 545 and 1217?
Maik Jablonski wrote: > > Sounds cool... I'm not sure if it's easy as you describe, but I hope so...:) Basically you just grep for URL1 in all dtml files, anywhere you see &dtml-URL1; or and change it to IIRC "REQUEST" is safe to use. The culprit in this case is likely in manage_tabs.dtml I've never been able to reproduce the "content_type" bug. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Policy for Collector-Issues 545 and 1217?
Maik Jablonski wrote: > Hi, > > there are two collector-issues related to problems when Zope-Objects get ids > like 'content_type' or 'URL1'. I think this problem exists for all names > used in the REQUEST-object or general acquisitionable attributes of > ObjectManagers. > > http://zope.org/Collectors/Zope/545 > http://zope.org/Collectors/Zope/1217 > I don't think that these issues cannot easily be solved in Zope2 without > breaking the whole acquisition-magic. Sure they can. The problem is DTML and people not correctly limiting their namespace stacks when they should. Its not pretty when fixed because the code gets extremely verbose, but thats price of DTML. > What to do? The problem exists, but a fix is hard to find... if at all. > Accepting? Rejecting? Accept, they are completely fixable. I've probably already fixed those bugs in my fork, I'll hunt around and see if I can find the relevant files and post followups to the bugs. -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The bleak Future of Zope?
Lennart Regebro wrote: > From: "Dieter Maurer" <[EMAIL PROTECTED]> > > I do not believe you. > > But I believe him. :-) Adding more framework code to a project as large as Zope already is, is adding complexity. It might help you get your project done faster, because the new tools are better suited to the job, but it doesn't simplify what a developer needs to know in the long run. There's nothing quite as telling as looking at the full set of methods available on a 3rd or 4th generation object. By the time you've crawled your way down the paths of all the inherited classes, you can usually uncover some fairly severe inconsistencies. The permissions associated with those methods are usually laughable by that point. Mashing 3 different permissions onto the same object meta data via 7 differen't APIs is complete HELL for people who want to program with any degree of security/privacy, and thats exactly what happens in a lot of these large add-on frameworks. -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: The bleak Future of Zope?
Jim Fulton wrote: > >Oh, and about Maik's comment that ZC is the bottleneck in Z2 dev--Jim, > > I think it was Andreas Ah, you're right, oh well apart from who said it... > >you might not agree with Maik, but hidden security bugs over a year > >old aren't something the rest of the community can do anything > >about. > > Are you suggesting that we hid them? As soon as we found out about > them, we mobilized the whole company to work on them. This was a > big deal that we put a lot of effort into over a fairly short time. > How is this evidence that we were a bottleneck? I think you're confusing the past with the present. There is at least 1 hidden security bug thats been sitting in the queue for a year *right now*. I'm not talking about the stuff that was fixed in the last audit. As for why they are hidden, well thats, the [EMAIL PROTECTED] collector that encourages it, and as ZC runs the collector that puts the ball squarely in ZC's court. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: The bleak Future of Zope?
Casey Duncan wrote: > On Wed, 21 Apr 2004 11:36:31 +0200 > Andreas Jung <[EMAIL PROTECTED]> wrote: > > > Some remarks from my side as a Zope2 core developer on this issue: > > > > The Z2 community and development is currently at a bad point: > > > > - very few people are contributing to the Z2 in terms of new code and > > bug > > fixes > > (see the tons of open bugs in the collector) > > I agree that bugs deserve more attention. We need to have more bug days. > I meant to suggest a date last week, but I got diverted. How would > people feel about next Thursday, April 29? Have a bug day, might as well. The problem with bug days is that they losing ground to the slow but steady trickle of new issues. A dedicated developer who camps on the Collector would help tremendously. Oh, and about Maik's comment that ZC is the bottleneck in Z2 dev--Jim, you might not agree with Maik, but hidden security bugs over a year old aren't something the rest of the community can do anything about. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Chris Withers wrote: > > The patch means that auth creds are never sent, only an auth token that's > valid for 20 mins or so, or you could set it to less. The token *is* the cred in that scenario, you can't not send some form credentials. > Can you explain the XSS risk when a client user is not permitted to write > HTML content to be stored by the app? The malicious code doesn't have to be stored in the app being attacked. Typically its part of a URI pointing to the app to attack and includes the xss payload. That URI however could be found any number of places... social engineering usually comes into play then to get the victim to click on it. While its typically easier to convince users to click a link if it comes from the same site it appears to be going to, (think about message board systems like slash where where hyperlinks in comments are usually suffixed by [domain.com] to give the user the ability to avoid goatse and such) in the end, what dictates the likelyhood of attack is the value of the service more than anything. [Sadly this doesn't dictate the likely hood of XSS holes getting reported on security lists, where people frequently post every about silly little backwater application they can find.] > >restrictions, etc. but few people will go through the trouble, and I'd > >wager most people using the various cookie-based auth folder products > >don't even know the risks. > > This I'd agree with, but I find the argument "this car's breaks only let me > stop in 1 mile, so there's no point in changing them so I can stop in 0.5 > miles" a poor one... Well, knock yourself out, I mean, clearly auth techniques based around cookies need a lot of additional protection. Those same protections, if written modularly, can usually be used to bolster HTTP auth as well, so there's no harm in writing them. Its convincing people to actually use the damned things thats the problem. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Chris Withers wrote: > PS: To make cookie auth properly secure, you really need to be working over > SSL only, and in addition, you should tweak CookieCrumbler further so that > it sets the secure session bit, meaning your sessions should only get > returned over a secure connection... mindyou, to get basic auth to be even > vaguely secure, you also need to be working over SSL ;-) The problem of using cookies for auth creds is a little more complex than that. The reality is, in a well written application, cookies should never be used to store auth creds, even if you only send them over SSL. The reason is that client side scripting languanges are usually permitted access to cookie structures whereas they are explicitly forbidden access to auth cred structures. This is one of the main things that makes cross-site scripting attacks dangerous. ...and given that Zope is already highly susceptible to cross-site scripting attacks... Of course you can limit the potential for serious damage with aggressive expiration, source address restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Move to subversion for source code control of the Zope and ZODB projects
Jim Fulton wrote: > > I propose to move from CVS to subversion for the Zope and ZODB projects; > > http://dev.zope.org/Zope3/MovingSCMToSubversion No complaints from me. I do wonder though... one thing I've noticed about ZC's CVS usage in the past is that you folks never export your code for releases. Indeed, the 2.7.0 source release wasn't even checked out with -P so there's a lot of goofy-looking empty directories in the tarball. A common idiom through a great deal of the code is: __version__='$Revision: 1.201 $'[11:-2] Now... thats a cute hack, but its also a silly waste of time. If releases were exported with -kv, it wouldn't be necessary. If you're going to switch to subversion, could I humbly suggest that you actually follow a release process that obviates the need for that kinda stuff? Changing revision control systems is a perfect time to do that kind of thing as everybody is the mode of learning new a process. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZPT for CSS, anyone?
Tres Seaver wrote: > >Stylesheets should always be static documents, a dynamic stylesheet > >defeats browser caching > > Not if the dynamism is based on user preferences, and if the > cache-control headers are set appropriately; in that case, the browser > (but not intermediate proxies) will still be able to cache the page. Yes, even if dynamism is based on user preferences. Stylesheets are a combinatory tool, thats what cascading is all about. Create seperate stylesheets for every preference value and combine them to achieve the desired presentation. Let ZPT and directives handle the user preference logic, you'll blow less energy on the back-end processing and your server-side caching will be that much more effective. > However, consider what happens to cacheability when the URLs of of > images referenced in a document are relative; the same problem can > afflict stylesheets, particularly in a setup where virtual hosting is in > play. Nothing happens to cacheability based on URI relativity. I fail to see how virtual hosting has anything to do with this either. If you're talking about object acquisition, thats a manufactured problem that Zope enables, but is avoidable by attention to the context your URIs will appear in. Just because acquisition lets an object be addressable by multiple URIs doesn't mean its a good idea to do so. > I strongly favor DTML over ZPT for those cases where you need to > generate dynamic "plain" text (mail, CSS, Javascript, etc.) Python Scripts are better for dynamic plain text, simply because they're less magical and don't have all the stupid namespace problems that DTML does. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT for CSS, anyone?
Dylan Jay wrote: > Actually my use case isn't really for dynamic stylesheets but for > absolute urls. I want to be able to edit say a filesystem site using > dreamweaver and have relative urls like background-image: > url(back.jpg) work, and then when this is used in a zope site such > as a plone site then have it use something like background-image: > url(http://site.com/back.jpg) to save on repeated requests. If the zope hierarchy matches your filesystem hierarchy, you shouldn't need to use absolute URIs. > The other possible use case might what plone does with dtml in it's > skins which is to define a color/font once and use it in many > places. I'm not that fussed about that one, but neither of them are > really dynamic. I don't use plone, so I couldn't speak to this. > What if there was a CSSFile that when loaded changes all urls to > absolute urls? That might be too specific but at least it does open > the dynamisim flood gates. Thats doing the work in the wrong place. If you have a one-time translation job, which is basically what you're asking for, then you should do it once before the object is placed into the zodb. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT for CSS, anyone?
Chris Withers wrote: > Dylan Jay wrote: > >disadvantage that the css is no longer valid once templated. ZPT of course > >would be the solution if CSS was XML, but alas :( > > I think ZPT is just fine for generating CSS. It coudl do with a plan text > mode, like it has an HTML and XML mode, but apart fro mthat, it rocks :-) Stylesheets should always be static documents, a dynamic stylesheet defeats browser caching and destroys the advantages over just inlining all the presentation markup. If you want to have dynamic style, you should use dynamic cascading & inclusion instructions, but the stylesheets themselves should remain static. As such, generating style in ZPT is a complete waste of time and effort. The File object is a much better fit. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT for CSS, anyone?
Dylan Jay wrote: > Has anyone had a go at building a new templating language for CSS files? No, because it isn't needed. 99.9% of the time a style sheet is static. > My current need for this is being able to put set correct absolute urls for > background images in a css file such that I can still use dreamweaver to do > visual editing. How do you do this with a normal ? Describe the process. Then we'll tell you how to use that very same process with a style sheet. > Speaking of which, absolute urls are a real pain. There must be a better way > of being able to edit files on a file system and have the server use > absolute urls without having to write expressions for every single > reference? Isn't there some equivilent to the html base tag to specify what > "/" means? Why are you bent on using absolute URLs for images in the first place? -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PageTemplateFile vs. Bindings vs. Security
Martijn Faassen wrote: > Shane Hathaway wrote: > >There certainly ought to be a way to create an unrestricted > >PageTemplateFile, though it should be an explicit step. > > That is a good suggestion. I'd like that option. It would also be a > potential performance benefit. > > On the other hand, in situations where the PageTemplate designers are > *not* security conscious (they're designers, not primarily programmers) > the option of explicit checks is useful. PageTemplateFile is a class used by Product authors, just like DTMLFile. If you can write a product, you are either security conscious or your product is worthless. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PageTemplateFile vs. Bindings vs. Security
Shane Hathaway wrote: > On Wed, 24 Mar 2004, Chris Withers wrote: > > That sounds mighty handy. What needs to happen for that to happen? > > A voluntary volunteer needs to volunteer voluntarily. I'll probably tackle it, but not before next month due to more immediate fires. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: serving static content faster
Chris McDonough wrote: > http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing Sounds good. WRT your comments on the need for a cache multiplexer so one can handle the case of HTTP cache control headers & opaque server-side caches working together--I'm really wondering if a better solution isn't to just remove the cache header manipulations from where they are now (in a seperate product) and integrate it more into an API any where object [that wants to] can use. HTTP cache control really is a protocol level thing, and the way its bundled as an add-on service right now feels pretty awkward. But anyway, thats a digression from the main thrust of your let them eat producer proposal, which I think is a good idea in general. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ...but I want to access 'a particular tuple' in that context!
Tres Seaver wrote: > > The 'iteritems' method of a dictionary returns an object of type > 'dictionary-iterator'; AccessControl.ZopeGuards makes no container > assertions about that type, although it *does* permit calling the > 'iteritems' method which returns an instance of it. > > I find it interesting that that module wraps 'iterkeys' and 'itervalues' > in its 'get_iter' checker, but allows unrestricted access to 'iteritems'. Yeah I saw that, which is why I asked about it, I couldn't decide if it was left sort of half-baked on purpose or not. I assume not, but I wanted to make sure. > The following patch will make your use case work (it would need to be > prettied up for Python < 2.3): OK, but really I'm more interested in having this supported in Zope proper, I can always use .items() instead of .iteritems() and soak the associated costs if I have to. Surely making iteritems use a guarded interator is the Right thing, yes? -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ...but I want to access 'a particular tuple' in that context!
Try this in a PythonScript:
d = {1:2}
for t in d.iteritems():
pass
Annoyingly, it raises Unauthorized: You are not allowed to access 'a
particular tuple' in this context
Is there a reason for this, or is it just part of
AccessControl/RestrictedPython that hasn't been fleshed out yet?
--
Jamie Heilman http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81. People said, "No, Holly,
she's not for you." She was cheap, she was stupid and she wouldn't
load -- well, not for me, anyway." -Holly
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] PageTemplateFile vs. Bindings vs. Security
w from within my product code so that I can selectively poke holes to allow container access where needed, or am I to be forcibly coerced into exposing my object to restricted code? And two, assuming I haven't overlooked some detail about why forcing PageTemplateFile to work within the calling security context is a good thing... Shouldn't we fix PageTemplateFile to work like DTMLFile wrt security? How hard is it going to be to do that? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] asyncore -> twisted
Duncan M. McGreggor wrote: > The Zope2 sprint has been focusing on HTTPServer, and one of > the interesting ideas that came up was to replace asyncore with > twisted. Several people have worked on this in the past, and we were > hoping that you could share your experiences, warnings, intuitions, > and hopefully even code :-) Meh. The event handling and multiplexed IO infrastructure isn't the part of Zope that needs the most work. Sure, you can replace ZServer with Twisted, but in the long run you aren't solving the big problems by doing so. If it makes you happy, if you feel its a prerequisite to getting any real work done, then you might as well do it. Nevertheless, you don't need everything that twisted brings just to serve a web page, and for the vast majority of Zope's users, serving web pages is the only service that anybody cares about. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
Lennart Regebro wrote: > OK, you get the problem that images may not load even if the main page does, > but is that really worse for the end user than not getting anything? As I've been saying, if you do that, they will reload repeatedly making the problem worse. If the images are fluf, and the user knows they are fluf, then *maybe* they won't reload, and your pages will simply appear ugly. But then you have to ask yourself, why am I sending fluf images that degrades the overall user experience of my application? Clearly there's more optimization that could be done to your application. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
Toby Dickenson wrote: > > Zope's ZServer manages a queue of requests that have been recieved over http, > but not dispatched to the publisher. This is handled in > PubCore/ZRendezvous.py. I suspect this queue will be holding your backlog. > > You might get some benefit from capping the length of that queue. Thats right! Yeah, true, it probably is holding the backlog as the default concurrency (on unix) is pretty high, but capping that queue ... I dunno, what do you with the new requests once its full? You're back to the problem of identifying sessions, and thats a potential mess. > Before creating a session, check the size of the ZRendezvous backlog. might > work. Yeah, thats a good plan in terms of where to instrument it, if you had to. If it were me, I'd sooner throw more hardware at it than use session identifiers though. -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
Bjorn Stabell wrote: > You'll always reach the bottleneck sooner or later, and in 99% of the > cases it'll be Zope. It's not exactly a racing horse. Tell me about it, in a former life I was the guy with the pager. > With KeepAlive on, wouldn't everything in one "session" sent over one > TCP connection? If that is the case, each accept() will basically > service a whole session, and so you should be able to do the easy thing > of refusing a connection just after an accept(). No, a session isn't that nice and tidy, clients can and do open multiple simultaneous connections, connection re-use and pipelining aren't all that define a session. If it were that easy, ZServer would do this already, so would, I imagine, Apache. Its not a pretty problem, which is why I suggest you spend your time looking at what you can do to scale better, or look for an Apache module that implements some sane-sounding session heuristic and give it a whirl, it will increase the resources needed by Apache, but maybe the costs will balance out. > We'll do that as well, but this problem is pretty serious; we can't > overload our server for even just a little while before latencies start > building up to ridiculous levels and users start hitting reload, further > compounding the problem. In the end we have to restart the server, same > as Dario reported. You'll have to move to load spreading, zeo, etc if you can't tweak your app any further. I personally feel that the ZEO seperation should be compulsary anyway, it just makes more sense, but I digress. Find yourself an Apache module that can spit out 503s, then work on load balancing infrastructure, which is probably the most viable longterm solution (next to simply not using Zope for something it evidently isn't very good at). -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
Bjorn Stabell wrote: > Basically, when the load gets high, Zope has a huge backload of work > (several minutes of requests), making the average latency for each > request many minutes. What are effective ways to do this kind of > overload management so that the backlog of work doesn't get that big? Make the app faster so that doesn't happen. > The ideal would be for requests to fail immediately if the backlog of > work is more than a certain number of requests (or even better, > estimated time to process). Kinda... > It appears the way to control it would for Apache or Zope to return "503 > Service Unavailable" when the load is too high, but we haven't found a > good way to do this; Zope doesn't appear to have any mechanism for it, > and Apache's ProxyPass doesn't either. I guess load balancers would, > but that's a bit overkill since we run the server on one machine. ...return 503 to every new request probably isn't a good idea, 503 to every new session is probably OK. Maybe. It depends on the workload. If you have a user who sends 10 requests and 5 of them fail, they're going to keep hitting reload to try to get them all to work, which just compounds your problems. The idea is that you want tweak it so some of your users get everything, and some get nothing, instead of everybody getting partials. This means you have to track sessions though... thats probably easier to do in ZServer than it is in Apache 1.3 just because of the process model, but that doesn't mean its easy. By default, Apache doesn't track sessions and do that kind of planned failure. There are probably modules that can enable that behavior. ZServer's multiplexed IO model just hides the accepting socket from the poller if its concurrency level is reached, and yeah, then the incoming connections end up in the backlog. You'd have to change ZServer so it handled those new requests instead, identified if they were part of a session, queued them up if they were, or spat out a 503 if they weren't. Frankly, I bet you'd have more fun just making your app faster. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem
Evan Simpson wrote: > Argh. Scripts need a __name__ defined, or various activities choke. It > can't be the Id of the Script, since that can contain '.', which screws > up imports in the Script. It can't be None, since that will cause this > problem. > > Are there hidden gotchas lurking around giving all Scripts the __name__ > "Script (Python)"? Other suggestions? Ages ago I suggested "__main__" because the newly instantiated code is sort-of a new top-level namespace for a sort-of python interpreter. But given all the issues that arrised with the other choices maybe there's lurking gotchas with "__main__" too. Anyway, thats my thought. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Resolved security-related collector issues for the public?
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. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Resolved security-related collector issues for the public?
Maik Jablonski wrote: > There are many admins / users out there who aren't able to do this > (maybe they should learn it, but that's another point). Installing Zope > 2.6.3 was a big mess (even renaming in the ZMI was broken) and most > people rolled back to 2.6.2. Some people run even 2.5.1 (lots of > Debian-Users etc.). Debian users who continue to use the 2.5.1 packages are being done an injustice, I agree, and its too bad, but the Debian security policy fails when a maintainer takes on a package they can't keep up with and the security team isn't able to step in and cover for them. It happens, the answer is usually to either find a new maintainer who can keep up, or remove the package from Debian. One of Debian's strengths though is that they don't hide this information, users are encouranged to review the bug tracking system to get a feel for a package's relative stability and weigh the risks on their own. > If we don't have a easy-to-install-security-fix for such people (or a so > called "stable" release, which works out of the box) we should a little > bit cautious about releasing exploits. That's my point... So you want to offer aide to the people who've bitten off more than they can chew, and your proposed solutions seem to be either: a) provide easy-to-swallow security fixes & timely vulnerability disclosure b) provide neither Given that ZC clearly doesn't have the resources available to do (a), irrespective of if its even technically feasible, we can rule it out. And (b), well (b) just screws everybody. Exploits are a byproduct of understanding the vulnerability, they're a natural part of experimentation and learning. You usually can't discuss a vulnerabilty without implying the exploit. If you really want to help people who can't help themselves, offer education, not censorship in the guise of protection. -- Jamie Heilman http://audible.transient.net/~jamie/ ...and no, I don't support the War On Terror. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Resolved security-related collector issues for the public?
Maik Jablonski wrote: > Normaly security-related stuff is not visible for the public... and > this seems to be good to avoid exploits etc. Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough. > Lots of security-stuff is fixed now, but I don't think that all people will > migrate their servers as soon as possible (due to limited time, the > experience of the Zope-2.6.3-"desaster", vacations, etc.pp.). Sure, thats true of every security hole. > With all the mentioned security-exploits in the collector out there, the > probability of attacks will rise. And I don't think that this will shed a > "good light" on Zope. meh. Good, bad, its irrelevant, but you can't pretend there weren't problems and expect anyone with a shred of a clue to take you seriously. If you want to establish trust, you can be honest with your community, or you can do a lot of hand waving trying to cover things up and make yourself look even worse. > My proposal: Can we have a delay for making security-related fixes public? > Just a month or two or so... Every hole thats been fixed has been publically known and detailed for well over 4 months at the latest, with the exceptions of: 615 & 1154 - sessioning machinery was losing security context 924 - object properties stored as unprotected mutables All the unrestricted operations in RestrictedPython that were found as a result of ZC's security audit. (And possibly the unicode crashing issue, which I think got discussed on a public list or something fairly recently.) Delays are pointless. The broken sessioning machinery was sitting in the collector for a year and 3 months. During that time 2 different people uncovered the issue (presumebly) independantly, and reported it. How many uncovered it and didn't report it? How exactly was ZC supposed to release a new version of Zope with the fixes but at the same time not divulge the nature of the security flaws? Release an obsfucated binary distribution and say "Trust Us"? That doesn't sound very much like open source. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope - SecurityFocus Newsletter #232 (fwd)
> Can anyone shed light on all of these? I know about some of them, but this > is quite a disturbingly long list... These fixes were mentioned in the last few announcements Brian made, as well as an explanation how several of the issues came to be found. The particular security focus message you've quoted is a summary of Brian's announcement. ... > Further analysis of these issues is currently underway. This BID will be > separated into individual BIDs upon completion of analysis. Interesting. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] post security update analysis
Jamie Heilman wrote: > Now that we've reached closure on some of the outstanding security > issues in Zope there's a lot of stuff in the Collector that needs to > be revisited... > > Brian Lloyd wrote: ... > > - Proxy rights on DTMLMethods transferred via acquisition > > I believe this means issue #743 and issue #977 can be resolved now. > Actually, #977 already was rejected IIRC but its never been marked as > public which is rather irritating. I've verified that this is the case, #977 should be made public, and #743 can resolved. > > - Improper security assertions on DTMLDocument objects > > probably fixes issue #865, but because Zope-HEAD doesn't actually run > right now, due to a myriad of other bugs, I actually haven't tested it I've tested this now, #865 can be resolved. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: "Error Value: iterable argument required" when adding objects
Jeremy Hylton wrote: > On Sat, 2004-01-17 at 18:30, Jamie Heilman wrote: > > Its desirable in some circumstances, but not all. Part of the problem > > is people tend to blindly follow the traditional approach to daemon > > design without bothering to actually do any critical thinking. > > I expect you don't intend to sound rude, but this gives the impression > you think I've failed to do some necessary critical thinking. Even if I > you think that, it's hardly diplomatic to point it out. No I don't think you failed in any way, sorry if I gave that impression. I intended to bemoan the overall state of what are generally espoused to be "best-practices" when it comes to daemon design. As you said, the umask code only comes into play when explicitly asked for, and I think thats a really good thing, my initial concern was that the umask would be set to a default value regardless of the parent process's properties. > > There are several very reasonable arguments for deviation from the > > historical approach. > > What are they? They were listed in the URIs, but the jist is that its better to let small dedicated programs handle the daemonization and supervision of long-running code, than it is to embed those gymnastics into the code itself. > I don't follow how this advice relates to the current discussion. > We're talking about whether zdrun.py should have a --umask option. Ah, well, you are maybe--to me I see an error thats carping about a missing "umask" attribute value and no mention of zdrun, so it wasn't immediately clear to me which aspects of zope the umask would apply to. Now that I know its part of a broad (entire process group) control mechanism I'm less concerned. > > Anyway, if you want to question authority, consider reading: > > http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html > > I don't see how this questions authority. It sounds entirely compatible > with the design of zdaemon. Well, yes, to an extent. There's a large breakdown when it comes to the design of event logging. > (The TCP/IP stuff doesn't apply to zdaemon, and Zope works > differently, but that's typical for app servers.) agreed > Are you familiar with zdaemon? In purpose yes, but I don't use it in production. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: "Error Value: iterable argument required" when adding objects
Jeremy Hylton wrote: > You should take it up with the sysadmin on the zodb-dev list who wanted > this feature :-). They already had it, they just need to learn how to take advantage of the environment they're working in. > Daemons don't set the umask by themselves; they only do it when a > sysadmin configures zdaemon to run with the --umask argument. Thats good. > All the advice I can find about writing daemon code suggests that > setting the umask is desirable. Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking. There are several very reasonable arguments for deviation from the historical approach. Perhaps the most relevant argument is the same old one about the Unix design philosophy; many small programs working together is more a flexible and ultimately useful approach than a monolithic one-program-does-it-all design. Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html or http://cloud9.hedgee.com./scribbles/daemon or even better yet, look back over the CVS commits and bugs fixed in the Zope code (or other traditional-design daemons) that have been related to the current design choices and think about how they could have arisen under the more modular approach and how they might have been fixed in those circumstances. -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: "Error Value: iterable argument required" when adding objects
Jeremy Hylton wrote: > I committed a patch with the umask option a few days ago. I thought it > only affected zdaemon and the tests all looked clean afterwards. I'm > not sure how zopectl.py ends up being affected or why there aren't any > tests of it. The various scripts to start and stop programs are usually > hard to test, but they're usually the source of a lot of bugs, too. Speaking as a sysadmin I'd like to suggest that the zope daemons make no efforts to frob thier assigned umasks in any way. Thats generally something the sysadmin will take care of during the startup scripts, and to have daemons change it after the fact because they think they know "better" causes no end of frustration. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] post security update analysis
Now that we've reached closure on some of the outstanding security issues in Zope there's a lot of stuff in the Collector that needs to be revisited... Brian Lloyd wrote: > - For loops, list comprehensions, and other iterations in untrusted code > - List and dictionary instance methods in untrusted code > - Use of import as in untrusted code > - Use of min, max, enumerate, iter, and sum in untrusted code > - Broken binding validation in untrusted code > - Unpacking in untrusted code > - PythonScript class security not initialized properly > - PropertyManager 'lines' and 'tokens' properties stored as list > - Configuration file did not override security policy selection AFAIK there weren't any public bugs related to these problems, except for maybe issue #28 which can probably be taken out of deferred status and placed into resolved now. > - Unicode passed to RESPONSE.write() could shutdown process I could have sworn there was a bug report related to this but I can't find it now. > - XML-RPC instance marshaling may disclose protected values issue #410, I can't comment on the effectiveness of this solution, I removed XML-RPC from my tree ages ago, I am currious if anyone has a test-case/exploit for this issue though > - DTML tag dtml-tree may allow DoS attack issue #604 can be marked resolved now > - Potential cross-site scripting problem in default ZSearch interface issue #734 can be marked resolved now > - Proxy rights on DTMLMethods transferred via acquisition I believe this means issue #743 and issue #977 can be resolved now. Actually, #977 already was rejected IIRC but its never been marked as public which is rather irritating. > - Improper security assertions on DTMLDocument objects probably fixes issue #865, but because Zope-HEAD doesn't actually run right now, due to a myriad of other bugs, I actually haven't tested it > - Inadequate security assertions on admin "find" functions issue #1000 can be marked resolved now The patchset for 813's xss issues seems to have been partially applied. I still need to update my patch against HEAD for the xss holes that haven't been closed. I'll post an update to the collector when its ready. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZServer HTTP 1.1 support
Paul Winkler wrote: > I noticed this in ZServer/README.txt (zope 2.6.2): > > HTTP 1.1 support is ZServer is incomplete, though it should work for > most HTTP 1.1 clients. > > Anybody know what specifically is "incomplete"? A lot of stuff. There's a also a good deal of just flat-out brokenness. HTTP/1.1 requests don't require a Host header in violation of rfc2616. ZServer responds with any arbitrary HTTP version number which causes all kinds of pain when migrating between new versions of the protocol. As it stands if a client comes and asks for HTTP/1.2 ZServer will respond with HTTP/1.2 which is bullshit because it doesn't know how to speak HTTP/1.2 and assuming it does is really dumb. AFAICT it doesn't coalesce headers with the same field name when the valus are comma-separated lists. ZServer will url-decode the entire request line, http version, method, all of it, before logging, not actually a HTTP/1.1 bug... just a random bit of stupidity I noticed. ZServer responds completely wrong to HEAD requests, we've all known about that one for ages. ZServer tries to swallow spurious CRLFs before the Request-Line but fails after two because it triggers a stage change (really not a terribly crucial bug, that ... I only mention it for completeness). ZServer doesn't look for message bodies when a Transfer-Encoding header is present, which violates all kinds of rules about the collection of message bodies. Treats HTTP/0.9 as HTTP/1.0, etc, etc, etc. The list goes on and on. None of which is a particularly big deal as long as you use a production quality gateway server that does its best to forward santized requests in front of ZServer. > In particular, some people on my team asked me if zserver > supports "persistent" connections, and I didn't know how > to answer. I'm looking now at HTTPServer.py and the docstrings > suggest that it does ... yes? no? To a fault. HTTP/1.1 requests will remain open (unless configured otherwise) for something like a half an hour IIRC, but the trigger to close them is another incoming request, which means on a quiet interface you can keep a single connection alive essentially forever (should you want to do that). Of course if you're keeping an HTTP session alive that long you're probably doing something completely sick and wrong and would be better off using a protocol more suited for long running task execution. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions
Toby Dickenson wrote: > Because > > / > > looks nicer than without the slash > > ? OT: Seeing as that would actually have to be written / to get anywhere close to reliable and secure behavior, calling dtml-anything "nice" seems to be a bit moot--bug 813 lives on. ...but anyway, I have no opinion on the absolute_url api one way or the other, its been so carry on... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime stftime and TAI based timezone is broken or is it?
Brad Clements wrote:
> Yesterday I switched my Linux machines to use clockspeed 0.62 and
> therefore had to switch to the right/EST5EDT timezone.
>
> Today my client calls rather upset that lots of data has disappeared
> from his database, etc..
Interesting, I've been using right/US/Pacific myself for ages but I
never experienced any pain from it. Then again, I never noticed
DateTime was getting stuff wrong until you pointed this out.
> >>> y = DateTime.DateTime(dx) y
> DateTime('2003/12/01')
> >>> y.strftime("%a %b. %d")
> 'Sun Nov. 30'
> >>> y.strftime("%a %b %d %H:%M:%S")
> 'Sun Nov 30 23:59:38'
Lovely. Its always bugged me that DateTime carried all its own zone
information, but I guess even the datetime python modules punt in this
regard. What I'm currious to know is how this caused problems for
you, or your clients. I'd like to avoid those problems myself if I
can help it.
--
Jamie Heilman http://audible.transient.net/~jamie/
"Paranoia is a disease unto itself, and may I add, the person standing
next to you may not be who they appear to be, so take precaution."
-Sathington Willoughby
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] cvs.zope.org down
Jens Vagelpohl wrote:
> This morning we noticed some odd activity on cvs.zope.org that
> looked like someone had broken into the machine.
...
> The collector.zope.org web site, which was served from the same
> machine, will probably end up being integrated into www.zope.org
> tomorrow and cease to exist as a separate Zope instance.
I'd like to make a request. If evidence reveals that
{cvs,collector}.zope.org *was* compromised, then would ZC kindly
consider making all 'security' bugs in the collector public?
The reasoning being that there is little point behind hiding potential
security problems from the zope community if the blackhat community
has already obtained the details. That said, any status on getting
the collector back up?
--
Jamie Heilman http://audible.transient.net/~jamie/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] possible compromise
Chris Pelton wrote: > Yes, that's what I'm thinking happened here, but I need to verify that > was the case. Are there any logs in zope that could help track this > down, or a known configuration that would allow it to happen? Several, the most common is people using mod_proxy incorrectly. Look for a ProxyRequests directive in your Apache config, if it exists and is on, chances are you have misconfigured Apache. Direct use of mod_proxy's directives is never necessary to use Zope. > Any ideas how someone might be able to tell Zope is running? You mean how somebody could fingerprint you from the outside? Well the Server header in the http response is the most obvious way, but certainly not the only one, zope's fingerprint is very distinct because of acquisition and its numerous management interfaces. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] possible compromise
Chris Pelton wrote: > So, would anybody have any ideas how to determine if this might have > been compromised? Or is there a known mail relay exploit through zope > somehow? I've checked system binaries and everything seems fine. None of > the python files seem to have been changed since well before the > relaying started. It might help to know the version of zope which you may be able to find it in the version.txt file distributed with zope releases. That said, there hasn't been a known relay exploit to the best of my knowledge, but there are many ways to implement a web application that sends mail in zope, and it wouldn't be at all surprising if the implementation of your system was vulnerable. Do you know enough about Zope to discuss the implementation of your web application? We can throw out a bazillion ideas but thats a painfully slow way to determine what really happened. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] Using 2.3.2 for Zope 2.7
Chris McDonough wrote: > OK, sounds like a slam dunk to me. I think its a fine idea (finally secure temporary files!), but let me present the first bug I've run into with 2.3 (I've been testing with it). In 2.3 you can no longer declare new classes in a Script object. It bitches about a lack of __name__ attribute. I haven't really had the time to look into it closely, but it does effect the examples shipped with zope, and actually its just a very useful thing to be able to do. Whatever this problem stems from, there will probably be more because of it. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Etag support in page templates
Jens Vagelpohl wrote: > I'm not looking at the big picture. I'm trying to avoid complaints from > people that for one reason or another use those broken M$ clients. Think about it: Solution A) # Directive: send-empty-etag # # Description: # Add an empty Etag HTTP header to server responses to placate # buggy Microsoft DAV clients. # # Default: off # # Example: # # send-empty-etag on # Directive: send-ms-author-via # # Description: # Add 'MS-Author-Via: DAV' HTTP header to server responses to # placate buggy Microsoft DAV clients. # # Default: off # # Example: # # send-ms-author-via on add, all the supporting code for this configuration and its implementation add, maintenance of said support code Result: The users will ask, "Why doesn't my Office application work with Zope?" The zope oracle will respond, "It can, but you have to enable the send-empty-etag and send-ms-author-via directives in your zope.conf." The user will respond, "OK, thanks." Solution B) in doc/WebDAV.txt or similar: Some Microsoft DAV clients are broken and need special coddling to work with Zope. In particular, extra headers need to be added to the HTTP responses. This can be done by configuring the HTTP proxy server to include these extra headers during conversations with known buggy clients. For example, using Apache's mod_headers: Headers set MS-Author-Via DAV Headers set Etag "" add, maintenance of said document Result: The users will ask, "Why doesn't my Office application work with Zope?" The zope oracle will respond, "It can, but you have to configure your HTTP proxy to overcome Microsofts buggy DAV implementation, read doc/WebDAV.txt for more information." The user will respond, "OK, thanks." Now... which of these scenarios do you think is in Zope's best interest? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Etag support in page templates
Jens Vagelpohl wrote: > Along with that the "MS Author Via" header garbage should at least be > governed by some configuration flag. No, no, no, you're not seeing the bigger picture... you don't need configuration flags for any of that stuff. It just shouldn't exist, period. If people need to clutter the protocol to make their clients work then they should do so with another filter program. In zserver's case thats going to be the proxy HTTP daemon that it talks to. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Etag support in page templates
Tres Seaver wrote: > The empty E-tag exists to support *very* broken clients (MSOffice over > WebFolders); it should be removed, perhaps with a knob which allows > re-enabling it for the sites that actually have people editing content > using those clients. Yeah it should be removed, but I'd say don't provide any way to add it back (apart from maybe some textual instructions in the doc directory or something). The thing that continues to baffle me is why people add braindamage like this to Zope at all. Its not the correct place to add dumb workarounds for dumber clients, the correct place is to use an external program that wraps the clean conversation and inserts this junk on the fly. I bet you could do it with apache's mod_headers for example. Same story for that MS-Author-Via junk. Poluting Zope's source code isn't the right answer. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FileUpload questions
Toby Gustafson wrote: >When a form is submitted with an , where are the > contents of the uploaded file stored? Is it automatically stored in the > ZODB, or is it stored in memory until some other code (like that in > Image.py) stores it? Its stored in a temporary file as defined by the tempfile module. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] CacheManager missing in 2.6.2b4 :-(
Chris Withers wrote: > Jamie Heilman wrote: > >2.2 because 2.1 lacks ruthless efficiency. > > That, on its own, is not a very helpful statement ;-) > What are the differences between 2.1 and 2.2 that you care about? 2.2 is installed on my machines, 2.1 isn't. It might work in 2.1 for all I know, but I'm not going to bother back-patch it even if it is possible, I'm simply not interested in supporting old versions of Python. (and no, I don't run Zope 2.6.x) > >The stock OFS/Cache.py is > >insecure, and lacking features I want, thus, I rewrote it and included > >patches to adapt the existing managers to the improved API. There is > >no third thing. > > Have you got a collector issue / Fishbowl proposal anywhere that is > looking to get this accepted? What reasons could people have for not > liking this new Cache.py? Yes, No, Read the collector issue. > >$ # screw with the headers to lib/python/OFS/Cache.py to replace \ > >ZopeCorp's eyesore of a copyright preamble > > With what? This kind of comment is a bit inflamatory and not at all > helpful :-( I'm just saying don't forget to add the preamble if you do check it in over the old library. (my Cache.py doesn't have it) Or don't. I don't care either way. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope] CacheManager missing in 2.6.2b4 :-(
Chris Withers wrote: > Jamie Heilman wrote: > >That depends on the cache replacement policy you need. If you're not > >tied to LFU then you can just switch to using my MemoryCache product. > >(With all the various caveats surrounding it, of course, python 2.2, > >patching Zope, etc.) > > Why Python 2.2? What's the patching you do? What's 'etc'? 2.2 because 2.1 lacks ruthless efficiency. The stock OFS/Cache.py is insecure, and lacking features I want, thus, I rewrote it and included patches to adapt the existing managers to the improved API. There is no third thing. > Have you submitted a collector issue for all this? If so, I might try and > work on it some time, although it's not an area I specialise in :-( > I wonder if anyone on this list could help out? Yes and no. Its issue 911. "Working on it" would require: $ cd your-zope-cvs-head $ w3m -dump http://audible.transient.net/zope/Cache.py > lib/python/OFS/Cache.py $ w3m -dump http://audible.transient.net/zope/cmassoc.diff | patch -p0 $ w3m -dump http://audible.transient.net/zope/cachemanagers.diff | patch -p0 $ # screw with the headers to lib/python/OFS/Cache.py to replace \ ZopeCorp's eyesore of a copyright preamble $ cvs commit Of course I'd happily invite peer review of my code. But none of that will fix that RAM Cache Manager's waste memory. Again, its just a choice that was made in RCM's design, less processing overhead w/the potential for more memory usage. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Mailinglists
Christian Theune wrote: > Hi, > > something went wrong on all zope.org mailinglists recently dunno anything about it, but I just thought I'd note that whatever happened it seems to have disappeared a good number of the list archives formerly hosted at http://mail.zope.org/ as well irritating -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.python.org/mailman/listinfo/zope-announce http://mail.python.org/mailman/listinfo/zope )
[Zope-dev] don't forget to install new modules
The DBTab merge to HEAD didn't include any updates to the setup stuff, hence it doesn't get installed, which kinda breaks everything if you aren't running out of the in-place source tree. Also adding to the zopeschema made zopectl blow-up. Dunno what the goal of that was. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] stopping the Version DoS
Leonardo Rochael Almeida wrote: > I didn't check the sources to see what solution was finally given to the > Version DoS attack, but I have a suggestion. Jim commited a fix, which AFAICT, puts the issue to rest. What his fix does is simply remove the version's db connections from the pool if the connecting user doesn't provide correct authorization creds. This sort of trades off 1 DoS for another if you want to get picky about it; now anonymous users can remove a version's db connections at will. Evidently, creating connections isn't expensive enough for this to really matter though, so I think the issue can be considered closed. Personally I'm just removing version support entirely from my tree. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] broken dtml document security
The security on DTML Documents seems to be hosed, see http://collector.zope.org/Zope/865 for way to reproduce it. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] BoboPOS 2
Whats the deal with all the code that refers to BoboPOS 2 in Zope. Why is it still there? -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] HelpSysectomy
Somebody mentioned wanting to get rid of HelpSys. For experimental purposes here's a patch that removes HelpSys requirements: http://audible.transient.net/zope/nohelpsys.diff Once this patch is applied you can rm -r lib/python/HelpSys Its not heavily tested, its made against CVS HEAD, have fun. Notes: I didn't bother patching Products/ZopeTutorial, I figure if you aren't going to bother with online help an online tutorial is earmarked for deletion as well. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] easy to fix bugs present in 2.7.0a1
Andreas Jung wrote: > >The fix for collector issue 342 was never included on CVS-HEAD and > >hence didn't make it into the 2.7 branch, it continues to only exist > >on the 2.6 branch. > > Fixed > >Collector issue 628, the ZMI textareas, as I recently mentioned on > >this list, are currently all out of wack. I've written patches to fix > >this and normalize their behavior, its all really simple stuff. For > >URLs to the patches see issue 628. > > Fixed > >Collector issue 953, this is a dead simple 1-liner problem/fix, and > >really should be fixed in both 2.6.2 and 2.7 > > Fixed Excelent, thank you! Jamie Heilman wrote: > Collector issue 799, dtml-tree still uses SCRIPT_NAME to generate the > base path for its plus and minus images, SCRIPT_NAME breaks badly when > Zope is proxied and has been discouraged since what... Zope 2.3 I > believe. The patch changes dtml-tree so it uses BASEPATH1 which works > correctly. I gather this bug has been lurking for so long because its probably not seen very often; it depends on how you set up zope, but here's a way to reproduce it, lest anyone think its not a real bug: using mod_rewrite+mod_proxy set up a path to access the root of zope-space which doesn't map to the root of apache's web space: RewriteRule ^/zope(.*) http://127.0.0.1:8080/VirtualHostBase/http/example.com:80/VirtualHostRoot/_vh_zope$1 [P,L] Everything works, except the +/- icons used by dtml-tree, with the patch, they work too. Looking at doc/HISTORY.txt we see that most of the SCRIPT_NAME->BASEPATH1 changes happend for Zope 2.3.0 alpha 1, but this one got missed. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] easy to fix bugs present in 2.7.0a1
The fix for collector issue 342 was never included on CVS-HEAD and hence didn't make it into the 2.7 branch, it continues to only exist on the 2.6 branch. Collector issue 799, dtml-tree still uses SCRIPT_NAME to generate the base path for its plus and minus images, SCRIPT_NAME breaks badly when Zope is proxied and has been discouraged since what... Zope 2.3 I believe. The patch changes dtml-tree so it uses BASEPATH1 which works correctly. Collector issue 628, the ZMI textareas, as I recently mentioned on this list, are currently all out of wack. I've written patches to fix this and normalize their behavior, its all really simple stuff. For URLs to the patches see issue 628. AFAICT, 2.7.0a1 never closes its open zodb connections, I mentioned this back in March and Fred said he'd look into it--was there any headway made on this? Collector issue 953, this is a dead simple 1-liner problem/fix, and really should be fixed in both 2.6.2 and 2.7 I'd also love to get some feedback on my queries re: Issue 28 ... Is there any reason that bug needs to remain deferred, list comprehensions certainly seem to work fine in 2.7.0a1 with python 2.2. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] raise_standardErrorMessage facilitates cross site scripting
Jamie Heilman wrote: > I have a feeling its atributable to either > raise_standardErrorMessage's "smart" tag searching, or some other > auto-magical aspect of the error handling framework. I finally got around to testing this hypothesis, and it seems to be true. raise_standardErrorMessage assumes anything stringish matching [a-zA-Z]> is markup and subsequently sets error_message, which normally isn't quoted. The problem is, while it may very well be markup there's no reason to trust it, as was shown with the case when int() is passed 'old', the error message may contain markup obtained from an untrusted source. So the question is, how much pain would it cause if there was mandate that error messages could not contain markup, and the behavior was changed so that error_message was always quoted, but assumed to be pre-formatted plain text? -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: weak examples, weak exploits
Chris McDonough wrote: > Jamie Heilman came up with a reasonable way to do this. The Zope Quick > Start page instructs the user to import the examples and gives him a > link which does so by calling manage_import. Actually... /me points at Casey ...not my idea, I just implemented a good suggestion. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weak examples, weak exploits
Jamie Heilman wrote: > Then call it http://host/aww_shit_now_what=old+flava' er, http://host/aww_shit_now_what?i=old+flava' rather. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weak examples, weak exploits
seb bacon wrote: > The file upload vulnerability was fixed in version 1.3 of Examples.zexp, > though. The reason it's still turning up in 2.6.x versions is probably > due to upgrades. Therefore I suppose additionally there should be a > patch which examines the ZODB on startup and prints a warning if an old > Examples folder is present. I opted for a patch that simply removes all the magic auto-install crud and goes for the installer link on the quick-start page. As for previous zope installations, well, I don't feel like trying to figure out how to examine the zodb and warn people if they've got bad examples still installed, it strikes me as too much junk in the startup procedure which is already too slow as it is. I say chalk it up as a lessoned learned and move on. As for my reworked examples, I added missing quoting to the navigation examples, size limits and entry limits to the guest book, size limits and entry limits to the file library, and additional sanity checking and robustness to just about everything. Examining the original advisory this is how I break it down: 1) moot with the addition of SiteErrorLog 2) Examples/db no longer exists in the Examples, I'm unaware if it ever did, at any rate, not a problem 3) moot with the addition of SiteErrorLog 3a) this is a problem, see below 3b) fixed in my reworking 3c) I was unable to reproduce this, maybe a bug with older Zopes? extra notes) wtf? I have no idea what the the advisory author was trying to say by including that diff, and I have feeling he doesn't know either. I mean, it has the words 'examples' and 'security' in it, but that doesn't make it relevant. There is unfortunately, a snag. One of the exploits (3a) as it turns out is actually a problem deeper down. To isolate a test case make a script like: ## Script (Python) "aww_shit_now_what" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters=i ##title= ## return int(i) Then call it http://host/aww_shit_now_what=old+flava' This can be disarmed by ensuring that in your standard_error_message you quote the results of error_msg, however this isn't the default, and it will result in a lot of broken and ugly looking (albeit safer) error pages. I haven't fully figured out exactly whats going on with that whole thing yet. I have a feeling its atributable to either raise_standardErrorMessage's "smart" tag searching, or some other auto-magical aspect of the error handling framework. (clues appreciated) In the mean time I suggest quoting error_msg. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weak examples, weak exploits
Casey Duncan wrote: > I would be in favor of making the Examples "opt-in" like the Zope > tutorial. It seems silly to have it in evey ZODB by default. Make > people add it if they want it. I aggree. Casey Duncan wrote: > Actually the add form could be linked from the Quick Start page to make it > really stupid simple. Totally. Patch and reworked Examples may be found at http://collector.zope.org/Zope/956 -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weak examples, weak exploits
seb bacon wrote: > No. Just go ahead and make the changes. It would be instructive for > others reading the examples to add a comment or two explaining the > rationale behind the extra checking code. 'k I can do that > The file upload vulnerability was fixed in version 1.3 of Examples.zexp, > though. The reason it's still turning up in 2.6.x versions is probably > due to upgrades. Therefore I suppose additionally there should be a > patch which examines the ZODB on startup and prints a warning if an old > Examples folder is present. You know, ironically, I don't think this "advisory" even covers that hole. There's obvious DoS potential in the guest book and such, but thats easily limited without degrading the value of the example. Anyway, I'll scrape over the examples and see what I can clean up. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] weak examples, weak exploits
http://exploitlabs.com/files/advisories/EXPL-A-2003-009-zope.txt This hit the full-disclosure list the other day. Vulnerabilities 1 and 3 are moot and have been since the introduction of SiteErrorLog. Although if the responsible parties had bothered digging a little deeper they'd have found the BCI HTTP headers and likely thrown a fit. Anyway, if you can wade your way past the all the spelling errors you'll see the 0day exploits are your typical abuse of badly code web apps, and apart from 1 and 3 there are probably legitimate bugs there. Your predictable response: There's just examples. Uninstall them. They shouldn't be left on a production system. Sure, you know that, I know that, my cat knows that. Joe Six Pack told me he knew, but he didn't care. Which tends to the be the consensus. But thats no excuse to be shipping bad examples. They should be fixed, bad examples are worse than no examples at all. I'll submit a fixed Examples.zexp but I need to know how its normally prepared, ownership, etc. Is there anything special I should do? -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: funky side-effects, possible bug in HTTPRequest.py
Jamie Heilman wrote: > > (the patches I spoke of should be ready sometime tomorrowish assuming > I don't run into any other funkyness, I'll post them to the collector) These are done, there's a synopsis available at http://collector.zope.org/Zope/628 and the patches are available at http://audible.transient.net/zope/resized.diff and http://audible.transient.net/zope/sqlsized.diff they apply against the HEAD branch, and they do use python 2.2 constructs as I don't think the issue is really critical enough to warrant making the next 2.6 release. I'm currious what opinions are on the idea of joining the dtpref_* usage and the sql_pref__* usage together. Good idea? Bad idea? (I think its a good idea, but then I don't use zsql methods anyway so I kinda don't care either.) -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] funky side-effects, possible bug in HTTPRequest.py
Dieter Maurer wrote:
> Zope promotes the variables from "cookies" and "form" to "other"
> at least since Zope 2.1.6 (the first version I worked with).
>
> I think this is for efficiency reasons. You have a single
> dictionary lookup instead of three ("other", "form", "cookie").
Yeah most promotion is for efficiency, but since 2.1.6 eh?
Interesting, that means its happening elsewhere too. Hmm. Yeah, I
see, it happens in __init__ for cookies, mmm and in processInputs for
form variables I guess. The difference I can see is two fold, first,
before 1.75 I believe promotion of form and cookies was only done
during request object creation, interestingly, its not done there
anymore from the looks of it; cookies and form vars are kept in their
seperate tainted & non-tainted buckets until they are fetched. Second
the promotion of cookies wouldn't clobber pre-existing keys in
other, interestingly, in 2.1.6 times, form vars would clober normal
other vars (URLx, BASEx, etc.).
I must admit, this isn't the biggest deal to me, I just blew quite a
bit of time tracking it down because I couldn't understand why the
promotion was happening and I don't like surprises, and nothing about
"def foo(self, bar, baz):" immediately jumped out and said to me,
"promote bar and baz form vars and cookies to the other dictionary."
Now that I have an appreciation for exactly how methods are published,
I see things in a different light of course.
--
Jamie Heilman http://audible.transient.net/~jamie/
"...thats the metaphorical equivalent of flopping your wedding tackle
into a lion's mouth and flicking his lovespuds with a wet towel, pure
insanity..." -Rimmer
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] funky side-effects, possible bug in HTTPRequest.py
Oliver Bleutgen wrote: > Jamie Heilman wrote: > >[major snippage] > > Hmmm, that means that this changes break exactly these applications, > which, in order to be on the secure side, explicitly use > REQUEST.form['bla'] more than once in a request, right. Naw, it doesn't break them, promotion doesn't mean the vars are actually moved from the form dictionary to the other dictionary, only copied. What it does is humble the poor shmuck who thought he knew the dangers of REQUEST.get well enough to use it without shooting himself in the foot. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] funky side-effects, possible bug in HTTPRequest.py
The last few days I've been working on patch to Zope 2 that will clean
up the textarea size preference handling in the ZMI. Right now, its a
mess. I kept running into this really irritating behavior such that,
when ever I'd go to pull something out of a request object, it'd end
up being found in the 'other' dictionary instead of where I expected
to be (which happened to be 'form'). After getting really curious as
to why this was happening I've managed to track it down to subtle a
change in the way that the HTTPRequest.get method worked between
revisions 1.75 and 1.74 (1.75 being mj's merge of the value tainting
code). The code responsible (assuming the value isn't tainted):
# Untrusted data *after* trusted data
v = self.form.get(key, _marker)
if v is not _marker:
other[key] = v # *boom*
return v
That magical promotion of the key & value to the other dictionary is
what tripped me up. This technique, while originally used only for
known convenience variables like URLx or BASEx and for promoting lazy
data, now applies to all variables after revision 1.75. (This isn't
the only spot it gets used now, the tainting changes made it affect
form values, cookies, tainted form values, etc.) It would increase the
speed at which variables are found--but I'm not sure its really an
intended side effect, and now I'll explain how I was bitten by it.
Its not unusual to see people write methods to be published that are
similar too:
manage_main = DTMLFile("edit", globals())
def manage_changeFoo(self, REQUEST, something=None, or_other=628):
# stuff
return self.manage_main(self, REQUEST)
They're a dime a dozen, yay neat. What sometimes makes them more
interesting is when people modify the REQUEST dictionaries to pull
off various behind the scenes fake-like-we-requested-it-that-way
stuff. This is what several of the methods that handled the Taller,
Wider, Narrower, etc. buttons on text area prefs did, and thats why I
ran into it. One of these methods did:
REQUEST.form.update({'something':'x', 'or_other':'y'})
and then it returned a DTMLFile plied with the snazzy new request that
had been tricked out with these fake values now stuck into the form
dictionary. This explains the TALES I saw that was
"request/form/something | request/something | default" which when I
first saw made wonder if the author was on acid. It was clear to me
that 'something' would never be in other, it wasn't a special variable
and it wasn't being explicitly stuck into the other dictionary by the
code, so why the redundant TALES I wondered? I removed the first
statement, and it broke the functionality. Hmmm!
Until about 20 minutes ago I didn't understand exactly how object
methods got published, but I tracked down the code in Publish.py and
found the mapply() function and now its all clear to me what was
happening. The request object gets mapply'd to the published method,
this means that any positional arguments or any keyword arguments will
get HTTPRequest.get'd out of the request object when they are applied
to the published method, and thanks to the side-effects from revision
1.75 on, it also means any named variables in a method definition will
be promoted into the HTTPRequest.other dictionary. Now, let me just say
- if thats how its supposed to be, so be it - but spin my nipple nuts
and call me Frank, this does NOT strike me as terribly intuitive
behavior.
Anyway, it was a learning experience for me, but I'm not convinced
this isn't a bug. What do you think?
(the patches I spoke of should be ready sometime tomorrowish assuming
I don't run into any other funkyness, I'll post them to the collector)
--
Jamie Heilman http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality. Before we know the words
for it, before we know there are words, out we come bloodied and squalling
with the knowledge that for all the compasses in the world, there's only
one direction, and time is its only measure." -Rosencrantz
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ./configure on Zope27HEAD with Python 2.2.2
Fred L. Drake, Jr. wrote: > Whatever happened to the old tried-but-true: > i=`expr $i + 1` nothing, its just overkill > I suspect using expr is more portable to the whole family of > sh-derived shells than any of the more new-fangled ways. Arithmetic expansion has been around for a long time, I wouldn't worry about it. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ./configure on Zope27HEAD with Python 2.2.2
> Does anyone care enough to fix configure to work properly on BSD? i=$(($i+1)) -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] version status
Chris Withers wrote: > Jamie Heilman wrote: > > > >100% correct. Frankly I'm not entirely convinced anonymous users > >should ever be able to open a zodb connection, > > Well, without that, they would never be able to view a page from a Zope > site. > That would make it tricky to log in ;-) By which I ment being assigned pre-allocated resources vs. allocating the resource during the request itself. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] version status
Brian Lloyd wrote: > Have you tested to ensure that the 2.6.2 (CVS) is still open to the > DoS? If so, could you give me a quick scenario that I could use to > reproduce it? I haven't tested 2.6.2, I tested CVS HEAD, assuming the code change to both was the validated_hook in Zope/App/startup.py then 2.6.2 is vulnerable as well. The hacky bash script I posted earlier was the test I used, but you can test it just by going to a host running the latest code and appending ?Zope-Version=foo to the URL. If it creates a new, persistent, zodb connection in the version foo, then you can be had. The rule of thumb is: if an anonymous client can force an application server to store persistent data accross transactions, then the server will be vulnerable to a DoS attack. Shane Hathaway wrote: > - Anonymous users can still open a versioned database connection > (although now they can't use it) > - Merely opening a versioned connection consumes resources > - Zope does not free those resources as it should 100% correct. Frankly I'm not entirely convinced anonymous users should ever be able to open a zodb connection, but I have no technical evidence to back that up, its just a hunch. Oliver Bleutgen wrote: > This is not purely aesthetical reasoning, since cookies can be trusted a > bit more than other variables coming from the request. You can't inject > them from third party sites, for instance. Well actually you can inject them from 3rd party sites if the browser is IE, but that probably doesn't come as a surprise to anyone, IE is notoriously insecure. Toby Dickenson wrote: > Ive not tested Jims code, but it looks to me like it *should* stop that > attack. Have you tested it? Yes, you get a 401 now, but by that time the damage has been done. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] version status
Whats the status of versions for 2.6.2 and 2.7? Have there been any decisions reached? I saw Jim's code get checked in but it won't stop the DoS I posted. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug day?
hopefully it will be a tad more successful than the last one -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Toby Dickenson wrote: > No criticism was implied public exploits are valuable part of > the security process. Its nice to hear not everyone in the industry has lost their mind. /me glances at redmond -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Toby Dickenson wrote: > ! # Disable nasty insecure version support. Thanks to > ! # Jamie Heilman and everyone one zope-dev Unless you're damning me with faint praise for posting an exploit, (which is fine) this issue was found by Oliver, not me. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)
Oliver Bleutgen wrote: > 2. Zope doesn't care if a correspondending Version instance to the value > of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for > the value of that Zope-Version variable at all. Hmm, it doesn't care, but it does store it in memory. Pardon my fugly non-portable bashisms here, but I just wanted to hash out an example: #!/path/to/bash exec >/dev/null h='http://victim.example.com/' for i in `seq 100`; do w3m -dump -post <(perl -e 'print "Zope-Version=",$ARGV[0]x50' $i) "$h" done Quick way to add 100 zodb connections and ~90M to the memory footprint with relatively little clue of who is responsible assuming traditional logging; presumeably one would get much trickier if they really wanted to obfuscate the source of attack, slowly crawling the site, changing the user-agent string, etc. Under sane resource limits the host is spared however the /Control_Panel/Database/manage_cacheParameters resource becomes unavailable due to memory constraints. Other side-effects from allowing anonymous clients to open additional zodb connections are as of yet unknown to me, anyone care to speculate on other vectors of abuse? -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Conflict Errors; how to track them down?
Chris Withers wrote: > Dieter Maurer wrote: > > > >The attached patch to "Zope/App/startup.py" provides this > >additional information. > > Where's the patch? http://marc.theaimsgroup.com/?l=zope-dev&m=105466926610469&q=p3 -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] manage_addZClass* permission question
Shane Hathaway wrote: > It is. Older Zope code uses the manage_ prefix to require the Manager > role by default. Needless to say, that strategy did not cope well with > later enhancements to Zope. OK. So what about the stuff in ZClasses/__init__.py, pure fluf? After yesterdays App.Permission bug I did a quick grep over the Zope source to make a big list of all used Permissions, and the 'Add Zope Class' in __init__.py is the only one I can't account for. (The one in Draft.py had me confused for a few minutes too before I found out that Drafts are completely disabled at the moment.) -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] manage_addZClass* permission question
I can't fathom the ZClass code. Can somebody tell me if manage_addZClass, manage_addZClassForm, and manage_subclassableClassNames are supposed to be protected by the 'Add Zope Class' permission, or if the code in ZClasses/__init__.py is pure fluf? That permission never shows up in any folder's security settings that I can see. VerboseSecurity has this to say about manage_addZClassForm: Unauthorized: Your user account does not have the required permission. Access to 'manage_addZClassForm' of (Product instance at 89189e0) denied. Your user account, meh, exists at /acl_users. Access requires one of the following roles: ['Manager']. Your roles in this context are ['Authenticated']. So it doesn't look like there is a named permission associated with those methods. I have to wonder if thats intentional. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WebDAV File Descriptor Leak
Brian Brinegar wrote: > Though we are planning to migrate to Zope 2.6.2 in early July. Are > there changes in Zope 2.6.2 that would effect this? I seem to recall CVS commit messages to the effect. > [EMAIL PROTECTED] (deleted) It should be noted, on a multiuser machine, /var/tmp is not a safe place to store Python 2.2.2 and earlier's insecure tempfile.py made files. Setting the TMPDIR variable for Zope to a directory which only the zope user may write to is recommended to avoid a potential DoS vulnerability. My understanding is that this is finally addressed in python 2.3. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] App.Permission security hole
Tooling through restructuring of my site I discovered a stupid
permissions problem. While App.Permission declares the 'Define
permission' perm it never gets initialized and thus
manage_addPermission{,Form} basically had weakened security. The
permission 'Access contents information' was still protecting the
method, but thats not adequate--that permission was never intented
(afaik) to represent "write access" to the zodb. By default, as the
'Access contents information' permission is granted to the Anonymous
user, anybody could fire off a request to
http://victimhost/Control_Panel/Products/x/manage_addPermission?id=foo&title=bar
where 'x' is some installed product (hey, why not use the HelpSys vuln
to find one that fits your fancy!) to add a permission object to
Product x. Anonymous users being allowed to bloat the zodb at the
least, possibly other issues at the worst (I don't know, I don't use
the ZClass machinery).
A quick refactor of App/Permission.py may be found at
http://audible.transient.net/zope/Permission.py which protects the
methods in question, however I have a hunch there may be more broken
here than this permission alone.
Testimonies on #zope indicate this affects 2.6.x as well as CVS, I
don't know how far back the bug goes (only due to sheer lazyness).
Collector report will be filed shortly, expect it to be hidden.
Workarounds: use the above Permission.py, or remove 'Access contents
information' from the Control_Panel/Products folder (and possibly
others)
--
Jamie Heilman http://audible.transient.net/~jamie/
"It's almost impossible to overestimate the unimportance of most things."
-John Logue
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPublisher.Client and encrypted passwords
Danny W. Adair wrote:
> At 10:23 AM 3/26/2003 +1100, Adrian van den Dries wrote:
> >On March 26, Danny W. Adair wrote:
> >> Thanks. How would I do that?
> >> ZPublisher.Client.call() is very convenient but only takes
> >> url,username,pwd...
> >
> >import base64
> >user, pass = base64.decodestring(req._auth.split(' ')[1]).split(':')
>
> Nice.
and then when the users's password contains a ':' ...
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ch-ch-ch-changes (post-merge fallout)
I'm slowly fumbling my way through the massive changes of the latest branch merge... am I missing where the open databases (Globals.opened) get closed, or did that just get dropped entirely (and if so, how does that relate to the goals of the clean shutdown work)? Also, now that the hacked asyncore is no longer wedged into place in ZServer/__init__.py are there any known gotchas if one should import say, Zope and running Zope.startup() before importing ZServer? Not that I plan on doing that mind you, but the side-effects that Zope 2 suffers from in its various import dependancies drive me up a wall. It'd be cool if that one got fixed. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
Christian Tismer wrote: > If you compare Zope's bug paranoia with Python's, would you > say Zope is a bit less concerned, or there are not enough > people being concerned to get things resolved? I don't really know, I don't follow Python all that closely. Though due cgi.py's usage of tempfile.py I set my TMPDIR to a directory only writable by my zope process owner, and I don't see that changing until python 2.3 though I haven't read over the rewrite. > Why I'm asking is simply because I'm concerned that there are > no bugtraq entries for Zope, and I don't buy that this comes > from Zope being bug-free. I don't think there's that many people actively auditing the source. All the bugs I've found haven't come from me looking for way a to do something malicious, they've come from me noticing bizzare behavior while trying to get something to work and just following up on it. > Maybe not enough people care about this, but if the hackers > also don't care, why should I :-) I don't know, why should you? I care because it used to be my job to care, now I can't seem to let the mentality go. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
Chris McDonough wrote: > I'm wondering if you might consider applying for checkin privileges. I've considered it. I don't think you need anymore cooks, maybe just a few more recipes. > The host header issue that you've uploaded several patches for is a > bonafide problem for some users, but I think that most people with > checkin privs feel that it isn't sufficiently dangerous to the majority > of users to take the time out to review all of your patches and vouch > for them via a checkin (this might take a day or so to do). Well then that either means I'm not explaining it well enough, or I'm wrong, or something. What I'm shooting for is some discussion of the issue, which to use bug 813 as an example, is why I asked for it to be made public. Even after going into more explicit detail on the zope list though I got exactly 0 followups, so I was starting to think people just didn't really care all that much. Thankfully this thread came along... > OTOH, if you could just check them in yourself, you would no longer > feel disenfranchised. I don't actually feel disenfranchised, just confused as to what kind of commitment to security ZC is making. My disapointment stems from my lack of ability to get any feedback on the bugs I've submitted. Its kinda happening now, but having to kick up dust to make it happen is less than ideal. I'm also worried about the amount of reported bugs versus the activity occuring to fix them. I understand many of them are probably "I did X and Y crashed, and gosh I think it might be a security problem in Z." without any analysis apart from random observation, which is sort of a pain in the ass to deal with, but they aren't visible, and thus I worry they aren't all like 493. (of which 494 is a public dupe ) -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
Max M wrote: > A statement like that without an argument is worthless in a discussion. > You need to elaborate as we cannot read your mind and see what lies > behind the statement. My statement wasn't really aimed at you, sorry, I'm not playing fair. My statement was aimed at people who don't have to read my mind because they've been informed, and I'm making it in a public forum to be a pain the ass. I've already mentioned I have outstanding security related bugs in the collector, and as Toby noted I've been vocal on the value of process seperation and resource limits. This isn't a coincidence. Without properly configured resource limits, it is trivial to use an exposed Zope instance to exhaust host resources. This isn't entirely Zope's problem, this is usually an issue of misconfiguration. For example, until Zope 2.6, ZServer imposed no length limits on HTTP request headers. (These headers are read directly into memory, thus it was fairly easy to exhaust the memory of a host without resource limits.) When I found that out I reported it as a bug, and it was promptly addressed. (kudos) Now it could easily be argued, and I wouldn't be inclined to really disagree, that header length limits should be configured by the fronting server. What I didn't appreciate at the time is just how important a front-end proxy server is for Zope. If you expose Zope to a hostile network, it is mandatory. So now I don't consider this kind of thing a bug in Zope, unless Zope happens to make it possible to drastically amplify the effects of such an attack, (at which point crashing zope by running it into a resource limit becomes trivial) and a front-end proxy is unable or unlikely to thwart the attack. Zope's bug collector hides security related bugs until they are deemed worth of display by the controllers. Personally I think full disclosure is preferable to secrecy, but I'm willing to play by the rules laid down as long as I think the system is working for the general benefit of the community. You may have noticed I haven't been terribly secretive about recent cross site scripting or cache poisoning issues, and that can be attributed to, in part, my growing disastifaction with the system. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
Lennart Regebro wrote: > 5. Protecting yourself against denial of service: > Zope does not seem to crash if you send random data to it, and I > have in logs seen attemps to overflow buffers and the like that > obviously are attempt to crash or break in to other (MS) servers, > without this affecting Zope at all. If you don't trust Zope in this, > you can put Apache in front of it. > > In this sense Zope is again VERY secure. No it isn't. (somewhere far in the distance Rainer Wolfcaststle is heard crying, "My RAM! The proxies, they do nothing!") ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
Christian Tismer wrote: > This is quite a silly argument, IMHO. No its not, you can't give exact answers to inexact questions with no prior understanding of how much foreknowledge the audience has. Especially when you're talking about security. > It is simple: Do I increase the possibility of somebody > to obtain root rights, or do I not? Given that there is no good reason to run Zope as root, assuming you don't configure Zope to fly in the face of reason, and assuming you discount the possiblity of exacerbating other external vulnerabilities your system may have (which is a stupid thing to discount IMO), then no, Zope doesn't increase the possiblity of obtaining root privileges. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
Christian Tismer wrote: > please excuse my ignorance, but I am asked from time to time how > secure or insecure Zope actually is, and I always have to say that I > actually don't know. Thats a good answer. Another one you might consider is, "2 liters" because there is no simple answer to that question. > There are people claiming that Zope opens a system to quite some > level, others claim the opposite. Ideally, Zope only opens the system to the extent the system administator allows it to. Resource limits, chroot jails, and so forth, are effective ways to de-fang many of the avenues available to zope users with the ability to instantiate dtml, script, and other such objects. Zope's ACLs also help an admin carve up their users into realms of trust. > Can someone please enlighten me and give me some details? > Especially, are there some Zope products considered especially > "insecure"? And, pondering more on security, are these issues, if > they exist, bounded to Zope itself, or becomes a system generally > more "open" to attacks, after Zope was installed? Generally, the more software you install, the more open to attack you are. If you don't need it, don't run it, and don't install it. Some Zope products may open up more avenues of exploit than others, thats why the admin should audit them before installing. > I don't mean to offend anybody by this, it is just a very simple > question which I cannot answer alone. No, its not a very simple question. If Zope was a small program with a single clear purpose, it might be. But Zope is a large framework with a multitude of directions. (A small program with a single clear purpose can not do what Zope does; let it be known I'm not suggesting Zope should be somehow packed into a small program with a single clear purpose. Broken up into several... perhaps, but thats a different thread.) Outside of the ideal world, unless extreme care is taken, software tends to have flaws with security ramifications. Last time I counted (March 1st.) there were 16 unaddressed issues in the Zope bug collector that had been marked as having security ramifications. Two of them are mine, and thus I feel confident in saying Zope is not as secure as it should or could be, but that if nothing else, the maintainers have been made aware of these shortcomings and that one can assume (if they should or not is a different matter) the issues will be taken care of. I will go on record as saying that, recently, response times to security related issues in the Zope2 tree have been disapointing. Construe from that what you will. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
Toby Dickenson wrote: > There is no amount of reconfiguration that can improve this in Zope2. Zope3 > promises to fix this, but with modular python components rather than modular > unix components. I would be interested in your thoughts on whether this makes > a difference. I don't think modular component libraries are a replacement for modular programs, or vice versa. They both have their place, they both can be good or bad depending on the implementation. (How's that for a wishy-washy say-nothing statement. ) I simply haven't looked seriously at Zope3 yet, because my needs and Zope3's timeline don't coincide. So unfortunately any opinons I could offer on Zope3's direction would be wholely uninformed. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
Chris McDonough wrote: > On Tue, 2003-03-11 at 17:48, Jamie Heilman wrote: > > How about, "a lot of code/documentation was removed, and a lot of new > > code/documentation was added." Don't get hung up on the exact > > numbers, my point was, a lot of work has gone into "simplifying" the > > configuration process, but that the bigger picture isn't any clearer > > for it. > > Given the circumstance, what would you propose to do? Merge and move on, I'm not asking anyone to throw out their work, just to give thought to what I've said. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
Jeremy Hylton wrote: > I don't know what work means in this context, but think the ZConfig > project is thorough. In my checkout there are 180k of document, 180k of > unit tests, and 136k of code. A measure of work that suggests that > something with 0k of documentation and tests and 136k of code would be > better makes no sense to me. How about, "a lot of code/documentation was removed, and a lot of new code/documentation was added." Don't get hung up on the exact numbers, my point was, a lot of work has gone into "simplifying" the configuration process, but that the bigger picture isn't any clearer for it. > I don't see where the UNIX philosophy has anything useful to say about > configuration, but maybe I'm just a closet unix hater <0.5 wink>. Small programs that do one thing well, written to work together, communicating via a universal interface, have the golden property of being easily replaceable. With this replaceability comes the ease of configuration. > I don't see that configuration gets any easier if you have multiple > processes. Even if Zope had N processes, there would still be the same > amount of stuff to configure. There is more than one way to ease configuration. Reducing the "amount of stuff" is one way, but sometimes, even after you've reduced till you can't reduce any further, there's still a lot of "stuff." Another way to ease configuration is to make things modular so its easier to visualize the flow of data. When the boundaries of communication are clearly defined between modules it becomes easier to understand what part each module plays, and how you can affect the overall result by changing or re-organizing the individual modules. > You'd probably still want a single master config file for the whole > thing, and a tool to check the configuration is valid separate from > the process that uses the file to configure itself. Not I. Large applications with a master config file are to be held with suspicion. Their longevity inevitably suffers because they are difficult to adapt to new situations. > As I watched everyone working on the ZConfig project, I was > impressed with how many issues are involved in getting a decent > configuration system. Indeed. > I don't think that break the server into multiple pieces would make > it easier to configure, and I don't see what requirements could have > been eliminated to make the project take less work. Well, when you've got some cycles to burn, give it some more thought. It may not be as obvious to you if you don't deal with it on a day to day basis like sysadmins do, but I assure you UNIX owes much of its longevity to the philosophies upon which it was built. Adaptability is a big deal. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
Steve Alexander wrote: > > But lo, still you won't be able to do something as > >mundane as limit the memory the FTP server is able to consume without > >affecting the HTTP server. > > You can do this with Zope. Just use ZEO and run one ZEO front-end for > HTTP and one for FTP. Sure, but then you carry along all the baggage of 2 zserver instances. Its a start, but there's still a ways to go. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
Chris McDonough wrote: > > Before dismissing it out of hand, I'd encourage you to try it out. I'm not dismissing it, and I think you need to go back and read what I wrote again very very carefully without reading anything into it. I'm not trying to imply that using environment variables to configure the current codebase will reduce the code footprint. Even if it did, because of the distributed nature of the technique, its damnedly hard to maintain in a project as large as Zope. Also, I didn't say ZConfig was 374k of code, I said it was 374k of *work*. I chose that word very carefully, and obviously thats going to err on the side of conservatism as certainly the work was not isolated to that single directory tree. The point I'm trying to make is that Zope has learned nothing from the UNIX philosophy. Yes, you can extend the config schema. You can grow new, better config files, of extraordinary magnitude. The all-powerful server will grow from being all-powerful to being all-powerful + n. It will be able to read mail. Its heralds shall sit upon mountain high throwns hewn of the finest O'Reilly and New Riders scripture. But lo, still you won't be able to do something as mundane as limit the memory the FTP server is able to consume without affecting the HTTP server. Fracture the server infrastructure into small, seperate processes. The configuration of the individual pieces becomes trivial. The understanding of the overall data flow improves. When there's nothing left to remove from code, you've won. Some of the breaks have already been made, like the separation of the storage from its front-end. Thats good, we need more action along those lines. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed installation changes for review
> - Environment variables are no longer used for configuration.
I'll say it one more time.
The roadmap[1] states under the "Simplifying the Zope experience"
section:
* simple tasks should be simple!
Now, code required to extract a value from the environment:
import os
try: value = sanitize(os.environ.get("SOMETHING", default))
except Unsanitary:
...cope...
# where 'sanitize' is in reference to any conversion procedures required
# prior to the use of 'value' by program code
Pretty simple. Enter ZConfig:
$ du -sk ZConfig
374 ZConfig
374k of work devoted to replacing os.environ.get and its sanitizing
code, and the result is a XML config file. I'm not saying this all
for naught, but really, it should give you pause. Just how much have
you really simplified configuration by doing this?
Personally I think the problem of Zope's configuration hassles has
been mis-identified. ZConfig cleans up and centralizes a maze of
badly strewn out configuration code. It will extend the lifetime of
the Über-server concept ZServer employs. It does nothing to prevent
the same mess from happening again, down the road. I believe a more
lasting approach is to seperate the servers into small individual
programs which only do 1 thing, and do it well. Then you combine
those servers under a unified mangement framework, connect them
together by using common communication idioms, the idea being--and
follow me here, to use small programs combined together to provide a
larger service. Sound familiar?
--
Jamie Heilman http://audible.transient.net/~jamie/
"...thats the metaphorical equivalent of flopping your wedding tackle
into a lion's mouth and flicking his lovespuds with a wet towel, pure
insanity..." -Rimmer
[1] http://dev.zope.org/Resources/ZopeRoadmap.html
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
