Re: [Zope-dev] Re: ZCatalog getObject broken

2005-03-21 Thread Chris Withers
Florent Guillaume wrote:
Ah, okay, I thought that's what you meant, but I hoped it wasn't.
The fact that you expect this to work is a bug in Zope's security 
machinery, IMHO, but sadly only IMHO it appears.
Huh? That's fundamental to Zope's security model.
As I said, I appear to be the only person who thinks differently. I 
don't believe it's fundamental to Zope's security policy myself, and I 
think Zope would be just fine and less suprising to those of us who 
value security if it all behaved like restrictedTraverse...

Well, you must be the only one who never had a need for security
restrictions elsewhere than at the root of the site.
I understand the pros and cons, don't worry ;-)
Chris
--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-18 Thread Florent Guillaume
Chris Withers  [EMAIL PROTECTED] wrote:
  A, B and C are folders nested in each other i.e. A/B/C. A user does not
  have access to A and B but he does have access to C. If getObject uses
  restrictedTraverse it returns None immediately when traversing A, even
  though the user is allowed to access C. If getObject was working
  properly it would have returned C.
 
 Ah, okay, I thought that's what you meant, but I hoped it wasn't.
 The fact that you expect this to work is a bug in Zope's security 
 machinery, IMHO, but sadly only IMHO it appears.

Huh? That's fundamental to Zope's security model.

 I would have no problem with the above behaviour if getObject raised 
 Unauthorized rather than returned None.
 
 Your patch still had it returning None, IIRC, why did it do that?
 
  The rest of the discussion basically boils down to figure out if the
  user is allowed to access C or not.
 
 Yep, personally I reckon EVRYTHING should behave like 
 restrictedTraverse, but as I said, that appears to just be me...

Well, you must be the only one who never had a need for security
restrictions elsewhere than at the root of the site.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-16 Thread Chris Withers
Roché Compaan wrote:
I don't get why you're not getting it :-)
A, B and C are folders nested in each other i.e. A/B/C. A user does not
have access to A and B but he does have access to C. If getObject uses
restrictedTraverse it returns None immediately when traversing A, even
though the user is allowed to access C. If getObject was working
properly it would have returned C.
Ah, okay, I thought that's what you meant, but I hoped it wasn't.
The fact that you expect this to work is a bug in Zope's security 
machinery, IMHO, but sadly only IMHO it appears.
I would have no problem with the above behaviour if getObject raised 
Unauthorized rather than returned None.

Your patch still had it returning None, IIRC, why did it do that?
The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.
Yep, personally I reckon EVRYTHING should behave like 
restrictedTraverse, but as I said, that appears to just be me...

Chris
--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-16 Thread Chris Withers
Roché Compaan wrote:
This is what I am arguing but I haven't had anybody agree/disagree with
me yet. It is also a lot simpler to fix:
 return self.aq_parent.restrictedTraverse(self.getPath(), None)
---
   return self.aq_parent.unrestrictedTraverse(self.getPath(), None)
I don't really mind either, provided the ,None vanishes...
Chris
--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-12 Thread Dieter Maurer
Max M wrote at 2005-3-11 19:10 +0100:
 ...
A single method might be public, but the rest of the object is hidden.

What to do then? Just ignore the public method and use the objects 
overall visibility?

The object has a ObjectPermission that controls handling references (!)
to the object (itself) in TTW code.
TTW code should not get a reference to an object when it does
not have the ObjectPermission on it.

Therefore, getObject tries hard to return None instead of the
object in these cases.

-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-11 Thread Chris Withers
Florent Guillaume wrote:
In the current getObject problem that concerns us, we want to do better
that restrictedTraverse,
Why? As far as any problems I had go, it was purely the returning None 
when the user can see the object that was the bug. Provided getObject 
raises unauthorised when a user isn't allowe to see something, that 
works for me.

Now, I'm obiously missing something, so what is the problem that you and 
Roché are having?

Chris
--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-11 Thread Roché Compaan
On Fri, 2005-03-11 at 15:47 +, Chris Withers wrote:
 Florent Guillaume wrote:
  In the current getObject problem that concerns us, we want to do better
  that restrictedTraverse,
 
 Why? As far as any problems I had go, it was purely the returning None 
 when the user can see the object that was the bug. Provided getObject 
 raises unauthorised when a user isn't allowe to see something, that 
 works for me.
 
 Now, I'm obiously missing something, so what is the problem that you and 
 Roché are having?

I don't get why you're not getting it :-)

A, B and C are folders nested in each other i.e. A/B/C. A user does not
have access to A and B but he does have access to C. If getObject uses
restrictedTraverse it returns None immediately when traversing A, even
though the user is allowed to access C. If getObject was working
properly it would have returned C.

The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.

-- 
Roché Compaan
Upfront Systems   http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-11 Thread Max M
Roché Compaan wrote:
The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.
Hasn't it been raised allready that there is no way of knowing that?
A single method might be public, but the rest of the object is hidden.
What to do then? Just ignore the public method and use the objects 
overall visibility?

--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-11 Thread Roché Compaan
On Fri, 2005-03-11 at 19:10 +0100, Max M wrote:
 Roché Compaan wrote:
 
  The rest of the discussion basically boils down to figure out if the
  user is allowed to access C or not.
 
 Hasn't it been raised allready that there is no way of knowing that?
 
 A single method might be public, but the rest of the object is hidden.

This is what I am arguing but I haven't had anybody agree/disagree with
me yet. It is also a lot simpler to fix:

 return self.aq_parent.restrictedTraverse(self.getPath(), None)
---
 return self.aq_parent.unrestrictedTraverse(self.getPath(), None)


-- 
Roché Compaan
Upfront Systems   http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-10 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
| Dieter Maurer  [EMAIL PROTECTED] wrote:
|
|Roché Compaan wrote at 2005-2-25 17:22 +0200:
|
| Last year in March the following checkin was made that changed
| ZCatalog's getObject to use restrictedTraverse instead of
| unrestrictedTraverse. See:
|
|http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
|
|In my opininion this is wrong,
|
|I agree with you!
|
|
| Me also.
|
|
|...
| I would propose that getObject does an unrestrictedTraverse of
| the path and then checks if the user has permission to access
| that the object.
|
| I argued precisely this approach with the person who made the
| change. I had the impression that I have convinced him -- but
| apparently, he did not change the code accordingly :-(
|
|Maybe, a bug report to the collector will help?
|
|   http://www.zope.org/Collectors/Zope
|
|
| Roché has added http://www.zope.org/Collectors/Zope/1713
|
| I intend to fix this before 2.7.5 final, probably today or tonight. I
| feel this is sufficiently important to warrant a fix now. I guess
| it'll mean an RC2.
|
| Please shout if you find problems with this approach.
Please note that calling 'validate' without passing the correct values
for 'container', 'accessed', and 'name' may lead to unexpected results
(it tries to guess, but may not be clever enough, especially if there is
any weird wrapping / unwrapping in play).  This was essentially the
issue which led to the spurious Unauthorized error problem in Zope
2.7.3 (this point is germane or issue #1534, as well as #1713).
Tres.
- --
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  Zope Dealers   http://www.zope.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMHBnGqWXf00rNCgRAvVZAJ9vlruC2X6Q60g8kzYpbcy8Rk8E/ACdGktW
4rPMryTLyixAABvKf/tj184=
=U7gY
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-10 Thread Chris McDonough
I implemented a publisherTraverse function like this FWIW:

def publisherTraverse(context, path):
# this is a hack to get around the fact that restrictedTraverse,
# unlike publisher traversal, does checks at every step of the
# path.  We don't want to limit access in this way (e.g. nested
# shares are possible) so we reimplement restrictedTraverse in a
# way that that emulates publisher traversal semantics
ob = context.unrestrictedTraverse(path)
user = getSecurityManager().getUser()
if not user.has_permission('View', ob):
raise zExceptions_Unauthorized, cant traverse to %s % path
return ob

Maybe this is better than using validate?

On Thu, 2005-03-10 at 11:06, Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Florent Guillaume wrote:
 | Dieter Maurer  [EMAIL PROTECTED] wrote:
 |
 |Roch Compaan wrote at 2005-2-25 17:22 +0200:
 |
 | Last year in March the following checkin was made that changed
 | ZCatalog's getObject to use restrictedTraverse instead of
 | unrestrictedTraverse. See:
 |
 |http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
 |
 |In my opininion this is wrong,
 |
 |I agree with you!
 |
 |
 | Me also.
 |
 |
 |...
 | I would propose that getObject does an unrestrictedTraverse of
 | the path and then checks if the user has permission to access
 | that the object.
 |
 | I argued precisely this approach with the person who made the
 | change. I had the impression that I have convinced him -- but
 | apparently, he did not change the code accordingly :-(
 |
 |Maybe, a bug report to the collector will help?
 |
 |   http://www.zope.org/Collectors/Zope
 |
 |
 | Roch has added http://www.zope.org/Collectors/Zope/1713
 |
 | I intend to fix this before 2.7.5 final, probably today or tonight. I
 | feel this is sufficiently important to warrant a fix now. I guess
 | it'll mean an RC2.
 |
 | Please shout if you find problems with this approach.
 
 Please note that calling 'validate' without passing the correct values
 for 'container', 'accessed', and 'name' may lead to unexpected results
 (it tries to guess, but may not be clever enough, especially if there is
 any weird wrapping / unwrapping in play).  This was essentially the
 issue which led to the spurious Unauthorized error problem in Zope
 2.7.3 (this point is germane or issue #1534, as well as #1713).
 
 Tres.
 - --
 ===
 Tres Seaver[EMAIL PROTECTED]
 Zope Corporation  Zope Dealers   http://www.zope.com
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.4 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
 iD8DBQFCMHBnGqWXf00rNCgRAvVZAJ9vlruC2X6Q60g8kzYpbcy8Rk8E/ACdGktW
 4rPMryTLyixAABvKf/tj184=
 =U7gY
 -END PGP SIGNATURE-
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 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 maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-10 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
| I implemented a publisherTraverse function like this FWIW:
|
| def publisherTraverse(context, path):
| # this is a hack to get around the fact that restrictedTraverse,
| # unlike publisher traversal, does checks at every step of the
| # path.  We don't want to limit access in this way (e.g. nested
| # shares are possible) so we reimplement restrictedTraverse in a
| # way that that emulates publisher traversal semantics
| ob = context.unrestrictedTraverse(path)
| user = getSecurityManager().getUser()
| if not user.has_permission('View', ob):
| raise zExceptions_Unauthorized, cant traverse to %s % path
| return ob
I don't think that the 'has_permission' check is quite right:  at least,
that isn't what the publisher does.  'ZPublisher.BaseRequest.traverse'
collects roles during the traversal, and then calls the user folder's
'validate', passing them at the end.  Note as well that 'View' may not
be the permission which is protecting the traversed-to object).
The correct emulation would probably be to call the user object's
'authorize' method, passing the proper values for accessed, container,
name, value, and roles.  Figuring out the proper values is left as an
exercise for the reader ;).
Oracular'ly,
Tres.
- --
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  Zope Dealers   http://www.zope.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMIAxGqWXf00rNCgRAicEAJ4xoSRVeFBDNGixfenZsXK58aN/zACfUbFF
SNfOYkCwgZyV30fl1H3ttko=
=rdT7
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-10 Thread Roché Compaan
On Thu, 2005-03-10 at 12:13 -0500, Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Chris McDonough wrote:
 | I implemented a publisherTraverse function like this FWIW:
 |
 | def publisherTraverse(context, path):
 | # this is a hack to get around the fact that restrictedTraverse,
 | # unlike publisher traversal, does checks at every step of the
 | # path.  We don't want to limit access in this way (e.g. nested
 | # shares are possible) so we reimplement restrictedTraverse in a
 | # way that that emulates publisher traversal semantics
 | ob = context.unrestrictedTraverse(path)
 | user = getSecurityManager().getUser()
 | if not user.has_permission('View', ob):
 | raise zExceptions_Unauthorized, cant traverse to %s % path
 | return ob
 
 I don't think that the 'has_permission' check is quite right:  at least,
 that isn't what the publisher does.  'ZPublisher.BaseRequest.traverse'
 collects roles during the traversal, and then calls the user folder's
 'validate', passing them at the end.  Note as well that 'View' may not
 be the permission which is protecting the traversed-to object).
 
 The correct emulation would probably be to call the user object's
 'authorize' method, passing the proper values for accessed, container,
 name, value, and roles.  Figuring out the proper values is left as an
 exercise for the reader ;).

Is it at all possible to figure out the proper values? Earlier in this
thread I asked if it is clear what value should be validated? It seems
to me that returning None when the user does not have access to the
object, imposes the same illogical constraint that the current
implementation does, in that it does not allow access to a method or
attribute of that object that is guarded less. One cannot predict when
calling getObject what method or attribute the user wants to access.

If it is possible to have access to a single method of the object but
nothing else of that object, then it doesn't make sense to do *any*
security checks in getObject. The object's own security assertions
should guard access to its attributes.


-- 
Roché Compaan
Upfront Systems   http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-03 Thread Max M
Roché Compaan wrote:
I'm unsure about the security check in the patch below - I copied the
way restrictedTraverse does it. I read through validate in the default
security policy but it is one of those methods where all the security
implications doesn't fit in your head all at once.
--- CatalogBrains.py~   2004-03-23 22:27:23.0 +0200
+++ CatalogBrains.py2005-03-03 09:43:48.0 +0200
@@ -47,7 +47,11 @@
 (i.e., it was deleted or moved without recataloging), or if the
user is
 not authorized to access an object along the path.
 
-return self.aq_parent.restrictedTraverse(self.getPath(), None)
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
+if obj and securityManager.validate(obj, obj, None, None):
+return obj
+else:
+return None

There is a method deep down in Zope somewhere called:
self.authenticated_has_access(obj)
I cannot find the definition on my local Windows install, so I assume 
it's defined in some c code somewhere.

Unfortunately there is no docs on the web either. Though there must have 
been at some time, as I would otherwise never have found it.

Hmm... that is odd.
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-03-03 Thread Roché Compaan
On Thu, 2005-03-03 at 09:27 +0100, Max M wrote:
 Roché Compaan wrote:
 
  I'm unsure about the security check in the patch below - I copied the
  way restrictedTraverse does it. I read through validate in the default
  security policy but it is one of those methods where all the security
  implications doesn't fit in your head all at once.
  
  --- CatalogBrains.py~   2004-03-23 22:27:23.0 +0200
  +++ CatalogBrains.py2005-03-03 09:43:48.0 +0200
  @@ -47,7 +47,11 @@
   (i.e., it was deleted or moved without recataloging), or if the
  user is
   not authorized to access an object along the path.
   
  -return self.aq_parent.restrictedTraverse(self.getPath(), None)
  +obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
  +if obj and securityManager.validate(obj, obj, None, None):
  +return obj
  +else:
  +return None
 
 
 There is a method deep down in Zope somewhere called:
 
 self.authenticated_has_access(obj)
 
 I cannot find the definition on my local Windows install, so I assume 
 it's defined in some c code somewhere.
 
 Unfortunately there is no docs on the web either. Though there must have 
 been at some time, as I would otherwise never have found it.
 
 Hmm... that is odd.
 

In this context the user does not need to be authenticated - Anonymous
might have view rights in the context of the object.

-- 
Roché Compaan
Upfront Systems http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
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: ZCatalog getObject broken

2005-02-25 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
|
|
| --On Freitag, 25. Februar 2005 20:21 Uhr +0100 Dieter Maurer
| [EMAIL PROTECTED] wrote:
|
| Roché Compaan wrote at 2005-2-25 17:22 +0200:
|
| Last year in March the following checkin was made that changed
| ZCatalog's getObject to use restrictedTraverse instead of
| unrestrictedTraverse. See:
|
| http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
|
| In my opininion this is wrong,
|
|
| I agree with you!
|
| ...
| I would propose that getObject does an unrestrictedTraverse of the path
| and then checks if the user has permission to access that the object.
|
|
| I argued precisely this approach with the person who made the
| change. I had the impression that I have convinced him -- but
| apparently, he did not change the code accordingly :-(
|
| Maybe, a bug report to the collector will help?
|
|http://www.zope.org/Collectors/Zope
|
|
| Best to include a patch as well :-)
And a new test which fails under the current code, but succeeds with the
patch. ;)
Tres.
- --
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  Zope Dealers   http://www.zope.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCH50UGqWXf00rNCgRAradAJ9/v/nU3iZEALYK+7hI2NYZCZbi0ACggAxm
l4LfqI3+RYCI8VRHV9cz0rU=
=4SWg
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )