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
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
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
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
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
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
[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.
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
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
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