Re: [Zope-dev] zope.i18messageid

2010-07-05 Thread Shane Hathaway
On 07/02/2010 11:49 AM, Tres Seaver wrote:
 Jim has asserted (but not really explained) that the C extension closes
 some kind of security hole.  I don't see any credible attack vector
 myself, but then I no longer believe it worthwhile to devote my own
 energy to defending against malicious TTW programmers.

FWIW, I imagine the problem is that zope.security treats 
zope.i18nmessageid as a rock, so if the implementation is in Python, it 
probably allows untrusted code to do this:

  msg.__setattr__.im_func.func_globals['__builtins__']['__import__']
built-in function __import__

I suggest the bug is in zope.security, which should never allow a type 
written in Python to be a rock.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.i18messageid

2010-07-05 Thread Jim Fulton
On Mon, Jul 5, 2010 at 12:57 PM, Shane Hathaway sh...@hathawaymix.org wrote:
 On 07/02/2010 11:49 AM, Tres Seaver wrote:
 Jim has asserted (but not really explained) that the C extension closes
 some kind of security hole.  I don't see any credible attack vector
 myself, but then I no longer believe it worthwhile to devote my own
 energy to defending against malicious TTW programmers.

 FWIW, I imagine the problem is that zope.security treats
 zope.i18nmessageid as a rock, so if the implementation is in Python, it
 probably allows untrusted code to do this:

   msg.__setattr__.im_func.func_globals['__builtins__']['__import__']
 built-in function __import__

 I suggest the bug is in zope.security, which should never allow a type
 written in Python to be a rock.

Although I wouldn't go so far as calling this a bug, I like the idea
of deciding whether to treat message ids as rocks depending on whether
we're using the C implementation or not.

Jim

--
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.i18messageid

2010-07-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tres Seaver wrote:
 Chris McDonough wrote:
 Fabio,
 
 Within the last few months you committed the following change to
 zope.i18nmessageid:
 
 http://svn.zope.org/zope.i18nmessageid/trunk/setup.py?rev=102497r1=101297r2=102497
 
 The commit message is Fixed the compilation of the C extension with
 python 2.6: refactored it as a setuptools Feature.  Can I ask what
 problem was being fixed with this commit?
 
 It undid work I did in this revision:
 
 http://svn.zope.org/zope.i18nmessageid/trunk/setup.py?rev=99669r1=97948r2=99669
 
 I should have left a comment in there: the work was effectively there to
 support building zope.i18nmessageid on Jython and other platforms like
 GAE that do not support C extensions at all, even optionally.  The
 package no longer builds on Jython (error: Setup script exited with
 error: Compiling extensions is not supported on Jython), although to be
 honest I don't really understand why not.  I'm hoping we can find a way
 to retain whatever fix you were trying to make but still allow the
 package to build on Jython, but I think I need to understand what
 problem you were fixing first.
 
 I think there is a good case for making the C extension an optional
 setuptools feature:  nobody acutally *needs* that extension built to
 have their application work.
 
 Jim has asserted (but not really explained) that the C extension closes
 some kind of security hole.  I don't see any credible attack vector
 myself, but then I no longer believe it worthwhile to devote my own
 energy to defending against malicious TTW programmers.
 
 The change here is to remove 'standard=True' from the feature
 constructor.  Developers who want the feature enabled can then build the
 egg via:
 
   $ python setup.py --with-codeoptimization bdist_egg
 
 We could then update the zc.recipe.egg:custom recipe to allow specifying
 features to be installed for a given egg.

I asked on the distutils SIG about the status of setuptools' Feature:
PJE basically said that they are deprecated / obsolete, which is why
they aren't documented.

I went ahead and packaged up the 'optional_build_ext' class which Chris
had previously inlined (into the setup.py of zope.i18nmessageid):

  http://svn.zope.org/zope.optionalextension/

  http://pypi.python.org/pypi/zope.optionalextension/1.1

The 1.1 release was to allow for using the package via 'setup_requires',
without having to install it manually first.  Unfortunately, setuptools
stomps on the 'command_packages' lookup, which means it only (currently)
works under plain distutils, and then only if you have already installed it.

I plan to investigate further to fix that problem.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwvi5wACgkQ+gerLs4ltQ4bVQCdH2zuP2slSgnQ16GiWOnPT2xb
5IEAoLzW/Jq9BL2gL5VgSxt+HyRj6i9j
=8ayy
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.i18messageid

2010-07-02 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris McDonough wrote:
 Fabio,
 
 Within the last few months you committed the following change to
 zope.i18nmessageid:
 
 http://svn.zope.org/zope.i18nmessageid/trunk/setup.py?rev=102497r1=101297r2=102497
 
 The commit message is Fixed the compilation of the C extension with
 python 2.6: refactored it as a setuptools Feature.  Can I ask what
 problem was being fixed with this commit?
 
 It undid work I did in this revision:
 
 http://svn.zope.org/zope.i18nmessageid/trunk/setup.py?rev=99669r1=97948r2=99669
 
 I should have left a comment in there: the work was effectively there to
 support building zope.i18nmessageid on Jython and other platforms like
 GAE that do not support C extensions at all, even optionally.  The
 package no longer builds on Jython (error: Setup script exited with
 error: Compiling extensions is not supported on Jython), although to be
 honest I don't really understand why not.  I'm hoping we can find a way
 to retain whatever fix you were trying to make but still allow the
 package to build on Jython, but I think I need to understand what
 problem you were fixing first.

I think there is a good case for making the C extension an optional
setuptools feature:  nobody acutally *needs* that extension built to
have their application work.

Jim has asserted (but not really explained) that the C extension closes
some kind of security hole.  I don't see any credible attack vector
myself, but then I no longer believe it worthwhile to devote my own
energy to defending against malicious TTW programmers.

The change here is to remove 'standard=True' from the feature
constructor.  Developers who want the feature enabled can then build the
egg via:

  $ python setup.py --with-codeoptimization bdist_egg

We could then update the zc.recipe.egg:custom recipe to allow specifying
features to be installed for a given egg.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwuJrEACgkQ+gerLs4ltQ6RbQCg1CMt5QlZV1DF45i0Elulu4+j
7QUAoL6DsbZOVElG15kLZBh9EbqJipc0
=D9/Y
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.i18messageid

2010-07-02 Thread Wichert Akkerman
On 2010-7-2 19:49, Tres Seaver wrote:
 The change here is to remove 'standard=True' from the feature
 constructor.  Developers who want the feature enabled can then build the
 egg via:

$ python setup.py --with-codeoptimization bdist_egg

 We could then update the zc.recipe.egg:custom recipe to allow specifying
 features to be installed for a given egg.

That would be a very welcome change for SQLAlchemy as well: it has an 
optional C extension to speed of marshalling data from SQL responses.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )