Re: [Zope-dev] Re: [Zope] Security Assertions

2002-01-17 Thread Chris McDonough

 I do not know what you mean by a 'monkeypatch' but it is certainly worth 
 it to add the patch to 2.3.x and 2.4.x branches.

Thanks very much for the patch!  We don't maintain 2.3.X anymore (at 
least not that I know of, although somebody probably should).  And the 
2.4 branch is a little up in the air at the moment.  There will be a 
2.4.4 to fix crashing issues but I don't know what the policy will be 
for introducing noncrash bugfixes.  2.5 already has the fix.

So... this is why I suggested a monkeypatch.  What I meant by 
monkeypatch is ... well, now you made me say it... hotfix.  There, I 
said it.  In other words, a Product that you can download and install 
that dynamically changes the running code without actually requiring 
that folks running 2.3.X/2.4.X patch their source code.

Note that this is *not* a vulnerability in case anybody gets nervous. 
It is a bug that has to do with Zope security, but it is not a 
vulnerability.  (That's why I didn't want to use the term hotfix)

You can make a monkey patch by creating code modeled after ZC hotfixes 
that does some specific set of steps.  In this case, you'd probably want 
to replace the ModuleSecurityInfo class/function with your fixed 
function dynamically.  Of course, in this case you'd need a way to 
arrange that it was among the first Products registered (in order for 
the other Products to make use of the patched function).  I think 
Products are initialized alphabetically, but may be wrong.  ;-(

-- 
Chris McDonoughZope Corporation
http://www.zope.org http://www.zope.com
Killing hundreds of birds with thousands of stones


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [Zope] Security Assertions

2002-01-17 Thread Adrian Hungate

Just a quick note on this point, there are two points during startup when a
product can get control:
1) When the __init__.py is imported
2) When the initialize function within that __init__.py is called.

These seem to occur quite far apart in terms of loaded modules so to get
something done early, do it at import time.

If you want a look at another monkeypatch type product, take a look at
PatchKit http://www.zope.org/Members/haqa/PatchKit .

Hope this helps

Adrian...

--
The difficulty of tactical maneuvering consists in turning the devious into
the direct, and misfortune into gain.
- Sun Tzu


- Original Message -
From: Chris McDonough [EMAIL PROTECTED]
To: Godefroid Chapelle [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, January 17, 2002 1:50 PM
Subject: Re: [Zope-dev] Re: [Zope] Security Assertions


  I do not know what you mean by a 'monkeypatch' but it is certainly worth
  it to add the patch to 2.3.x and 2.4.x branches.

 Thanks very much for the patch!  We don't maintain 2.3.X anymore (at
 least not that I know of, although somebody probably should).  And the
 2.4 branch is a little up in the air at the moment.  There will be a
 2.4.4 to fix crashing issues but I don't know what the policy will be
 for introducing noncrash bugfixes.  2.5 already has the fix.

 So... this is why I suggested a monkeypatch.  What I meant by
 monkeypatch is ... well, now you made me say it... hotfix.  There, I
 said it.  In other words, a Product that you can download and install
 that dynamically changes the running code without actually requiring
 that folks running 2.3.X/2.4.X patch their source code.

 Note that this is *not* a vulnerability in case anybody gets nervous.
 It is a bug that has to do with Zope security, but it is not a
 vulnerability.  (That's why I didn't want to use the term hotfix)

 You can make a monkey patch by creating code modeled after ZC hotfixes
 that does some specific set of steps.  In this case, you'd probably want
 to replace the ModuleSecurityInfo class/function with your fixed
 function dynamically.  Of course, in this case you'd need a way to
 arrange that it was among the first Products registered (in order for
 the other Products to make use of the patched function).  I think
 Products are initialized alphabetically, but may be wrong.  ;-(

 --
 Chris McDonoughZope Corporation
 http://www.zope.org http://www.zope.com
 Killing hundreds of birds with thousands of stones


 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [Zope] Security Assertions

2002-01-17 Thread Chris McDonough

 Just a quick note on this point, there are two points during startup when
a
 product can get control:
 1) When the __init__.py is imported
 2) When the initialize function within that __init__.py is called.

I think Godefroid's case it would definitely want to be in __init__.py
*outside* of the initialize() function as it wants to be done at the
earliest possible time.

- C



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )