June 2003 - Zope-Dev

Heads-up: 2.6.2 b3 and 2.7 a1 releases
by Brian Lloyd 27 Jun '03

27 Jun '03

Hi all - As far as I know, all of the outstanding tasks to cut Zope 2.6.2 b3 are complete, and all of the items considered important to get into the 2.7 alpha 1 have been merged. I'd like to plan to make both releases this Friday if possible, so if you know of something that I've missed that still needs to be done (for either release), please let me know ASAP. Thanks! Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

2 1

raise_standardErrorMessage facilitates cross site scripting
by Jamie Heilman 27 Jun '03

27 Jun '03

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 '<b>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

1 0

weak examples, weak exploits
by Jamie Heilman 24 Jun '03

24 Jun '03

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

10 17

Re: [Zope-dev] weak examples, weak exploits
by Jamie Heilman 24 Jun '03

24 Jun '03

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

1 0

zopeinstall, error in zope2.7 cvs
by PieterB 23 Jun '03

23 Jun '03

Hi, My first version of the zopeinstaller is available. It currently only build Python 2.2.3 and Zope 2.7, but I would like to enhance it to a full 'tinderbox'. See http://zwiki.org/PythonZopeTinderbox for details. It currently builds Python 2.2.3 from tarball and Zope 2.7 from CVS. It uses 'aap' to do so (http://www.a-a-p.org) For the first version of the main.aap of Zope, see http://gewis.nl/~pieterb/zope/zopeinstall/ I found one error in Zope2.7 CVS while working on the script. Zope doesn't seem to mind the <http-port> section in etc/zope.conf I changed the address, but the zopeserver started at port 8080 (default). This is my first installer/a-a-p-scripts, so please give feedback. Regards, PieterB -- http://zwiki.org/PieterB

1 0

Ordered Folder again
by Florent Guillaume 23 Jun '03

23 Jun '03

Hi, I'm sorry to revisit an problem that I see has been discussed to death last month, but I'd like to propose a change to what has currently been checked in about Ordered Folders into Zope 2.7. What I often want is an easy way to migrate existing sites to the ordered version. So I would propose that all Folders have OrderSupport, but with the following change: - in a folder, has_order_support would be either a boolean, or not present and thus found by acquisition - the zope root would have has_order_support = 0 - OrderSupport.manage_renameObject would do its special stuff only if self.has_order_support is true - dtml/main.dtml would test ordering with a simple <dtml-let hasOrderSupport=has_order_support> - dtml/folderAdd.dtml would present the user with a choice to basically decide if has_order_support should be set, unset or acquired. - manage_addFolder would take this additional argument and do nothing or create a property for has_order_support. Thus the default behavior would be the same as today, but if a folder is created with the has_order_support property (or if it's set after creation), the subtree would then be ordered. In a CMS that's always what we want. What do you think ? I think it gives the best of both worlds, as it's then very easy to migrate a site. The only downside is, I think that products like BTreeFolder2 would have to add an has_order_support=0 class variable. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

2 5

RE: [ZODB-Dev] BTrees & 2.6.2b3?
by Tim Peters 23 Jun '03

23 Jun '03

[seb bacon] > Just a quick repeat from last week in case it slipped from > anyone's radar... Here is the important bit again: > > a) Any reason why I shouldn't merge BTree bugfix(es) into the > 2.6 branch? > b) If "no", how about a 2.6.2b3? Specifically which changes do you have in mind? The one here: > http://cvs.zope.org/Zope/lib/python/BTrees/BTreeItemsTemplate.c.diff?r1=1.17 &r2=1.18 was backported to the 2.6 branch last week. There are now many active versions of the btree code (Zope2 head, Zope3 head, ZODB3 head, Zope-2_6-branch, ZODB3-3_1-branch, and ZODB3-3_2-branch are the ones I try to keep track of -- with *some* success <wink>), and not all changes in all branches belong in all other branches.

2 1

BTree fixes in a release?
by seb bacon 23 Jun '03

23 Jun '03

There lave been various BTree fixes lounging in the HEAD since Jan 2003 which I'd like to get into a release, basically because we have seen one of the bugs causing segfaults in production - this is the culprit: http://cvs.zope.org/Zope/lib/python/BTrees/BTreeItemsTemplate.c.diff?r1=1.1… a) Any reason why I shouldn't merge it into the 2.6 branch? b) Any chance of a 2.6.2b3? Seb

3 4

funky side-effects, possible bug in HTTPRequest.py
by Jamie Heilman 23 Jun '03

23 Jun '03

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

7 9

Memory Error
by Andy McKay 23 Jun '03

23 Jun '03

If you've visited ZopeZen you might have noticed this lovely error that seems to occur intermittently.. [snip rest of traceback] * Module Products.CMFCore.CatalogTool, line 214, in searchResults * Module Products.ZCatalog.ZCatalog, line 619, in searchResults * Module Products.ZCatalog.Catalog, line 732, in searchResults * Module Products.ZCatalog.Catalog, line 480, in search * Module Products.PluginIndexes.common.UnIndex, line 365, in _apply_index * Module ZODB.Connection, line 534, in setstate MemoryError: (Also, an error occurred while attempting to render the standard error message.) Its: Zope 2.6.1 (source release, python 2.1, linux2) python 2.1.3 openbsd3 I believe all the appropiate python stack patches are applied. Any ideas? -- Andy McKay http://www.agmweb.ca

5 7