I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:
http://code.google.com/p/googleappengine/issues/detail?id=671
Based on his code (the file secure.py is all you need, included in
secure.tar.gz) it seems he believes the only security leaks are
__subclasses__, gi_frame and gi_code. (I have since convinced him that
if we add "restricted" guards to these attributes, he doesn't need the
functions added to sys.)
I don't recall the exploits that Samuele once posted that caused the
death of rexec.py -- does anyone recall, or have a pointer to the
threads?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Alright, I will re-submit with the contents pasted. I never use double
backquotes as I think them rather ugly; that is the work of an editor
or some automated program in the chain. Plus, it also messed up my
line formatting and now I have lines with one word on them... Anyway,
the contents of PEP 3145:
PEP: 3145
Title: Asynchronous I/O For subprocess.Popen
Author: (James) Eric Pruitt, Charles R. McCreary, Josiah Carlson
Type: Standards Track
Content-Type: text/plain
Created: 04-Aug-2009
Python-Version: 3.2
Abstract:
In its present form, the subprocess.Popen implementation is prone to
dead-locking and blocking of the parent Python script while waiting on data
from the child process.
Motivation:
A search for "python asynchronous subprocess" will turn up numerous
accounts of people wanting to execute a child process and communicate with
it from time to time reading only the data that is available instead of
blocking to wait for the program to produce data [1] [2] [3]. The current
behavior of the subprocess module is that when a user sends or receives
data via the stdin, stderr and stdout file objects, dead locks are common
and documented [4] [5]. While communicate can be used to alleviate some of
the buffering issues, it will still cause the parent process to block while
attempting to read data when none is available to be read from the child
process.
Rationale:
There is a documented need for asynchronous, non-blocking functionality in
subprocess.Popen [6] [7] [2] [3]. Inclusion of the code would improve the
utility of the Python standard library that can be used on Unix based and
Windows builds of Python. Practically every I/O object in Python has a
file-like wrapper of some sort. Sockets already act as such and for
strings there is StringIO. Popen can be made to act like a file by simply
using the methods attached the the subprocess.Popen.stderr, stdout and
stdin file-like objects. But when using the read and write methods of
those options, you do not have the benefit of asynchronous I/O. In the
proposed solution the wrapper wraps the asynchronous methods to mimic a
file object.
Reference Implementation:
I have been maintaining a Google Code repository that contains all of my
changes including tests and documentation [9] as well as blog detailing
the problems I have come across in the development process [10].
I have been working on implementing non-blocking asynchronous I/O in the
subprocess.Popen module as well as a wrapper class for subprocess.Popen
that makes it so that an executed process can take the place of a file by
duplicating all of the methods and attributes that file objects have.
There are two base functions that have been added to the subprocess.Popen
class: Popen.send and Popen._recv, each with two separate implementations,
one for Windows and one for Unix based systems. The Windows
implementation uses ctypes to access the functions needed to control pipes
in the kernel 32 DLL in an asynchronous manner. On Unix based systems,
the Python interface for file control serves the same purpose. The
different implementations of Popen.send and Popen._recv have identical
arguments to make code that uses these functions work across multiple
platforms.
When calling the Popen._recv function, it requires the pipe name be
passed as an argument so there exists the Popen.recv function that passes
selects stdout as the pipe for Popen._recv by default. Popen.recv_err
selects stderr as the pipe by default. "Popen.recv" and "Popen.recv_err"
are much easier to read and understand than "Popen._recv('stdout' ..." and
"Popen._recv('stderr' ..." respectively.
Since the Popen._recv function does not wait on data to be produced
before returning a value, it may return empty bytes. Popen.asyncread
handles this issue by returning all data read over a given time
interval.
The ProcessIOWrapper class uses the asyncread and asyncwrite functions to
allow a process to act like a file so that there are no blocking issues
that can arise from using the stdout and stdin file objects produced from
a subprocess.Popen call.
References:
[1] [ python-Feature Requests-1191964 ] asynchronous Subprocess
http://mail.python.org/pipermail/python-bugs-list/2006-December/
036524.html
[2] Daily Life in an Ivory Basement : /feb-07/problems-with-subprocess
http://ivory.idyll.org/blog/feb-07/problems-with-subprocess
[3] How can I run an external command asynchronously from Python? - Stack
Overflow
http://stackoverflow.com/questions/636561/how-can-i-run-an-external-
command-asynchronously-from-python
[4] 18.1. subprocess - Subprocess management - Python v2.6.2 documentation
http://docs.python.org/library/subprocess.html#subprocess.Popen.wait
[5] 18.1. subprocess - Subprocess management - Python v2.6.2 documentation
http://docs.python.org/library/subprocess.html#subprocess.Popen.kill
[6] Issue 1191964: asynchronous Subprocess - Python tracker
http://bugs.python.org/issue1191964
[7] Module to allow Asynchronous subprocess use on Windows and Posix
platforms - ActiveState Code
http://code.activestate.com/recipes/440554/
[8] subprocess.rst - subprocdev - Project Hosting on Google Code
http://code.google.com/p/subprocdev/source/browse/doc/subprocess.rst?spec=s…
[9] subprocdev - Project Hosting on Google Code
http://code.google.com/p/subprocdev
[10] Python Subprocess Dev
http://subdev.blogspot.com/
Copyright:
This P.E.P. is licensed under the Open Publication License;
http://www.opencontent.org/openpub/.
On Tue, Sep 8, 2009 at 22:56, Benjamin Peterson <benjamin(a)python.org> wrote:
> 2009/9/7 Eric Pruitt <eric.pruitt(a)gmail.com>:
>> Hello all,
>>
>> I have been working on adding asynchronous I/O to the Python
>> subprocess module as part of my Google Summer of Code project. Now
>> that I have finished documenting and pruning the code, I present PEP
>> 3145 for its inclusion into the Python core code. Any and all feedback
>> on the PEP (http://www.python.org/dev/peps/pep-3145/) is appreciated.
>
> Hi Eric,
> One of the reasons you're not getting many response is that you've not
> pasted the contents of the PEP in this message. That makes it really
> easy for people to comment on various sections.
>
> BTW, it seems like you were trying to use reST formatting with the
> text PEP layout. Double backquotes only mean something in reST.
>
>
> --
> Regards,
> Benjamin
>
Which I noticed since it's cited in the BeOpen license we still refer
to in LICENSE. Since pythonlabs.com itself is still up, it probably
isn't much work to make the logos.html URI work again, but I don't know
who maintains that page.
cheer,
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
Hello everyone.
I see several problems with the two hex-conversion function pairs that
Python offers:
1. binascii.hexlify and binascii.unhexlify
2. bytes.fromhex and bytes.hex
Problem #1:
bytes.hex is not implemented, although it was specified in PEP 358.
This means there is no symmetrical function to accompany bytes.fromhex.
Problem #2:
Both pairs perform the same function, although The Zen Of Python suggests
that
"There should be one-- and preferably only one --obvious way to do it."
I do not understand why PEP 358 specified the bytes function pair although
it mentioned the binascii pair...
Problem #3:
bytes.fromhex may receive spaces in the input string, although
binascii.unhexlify may not.
I see no good reason for these two functions to have different features.
Problem #4:
binascii.unhexlify may receive both input types: strings or bytes, whereas
bytes.fromhex raises an exception when given a bytes parameter.
Again there is no reason for these functions to be different.
Problem #5:
binascii.hexlify returns a bytes type - although ideally, converting to hex
should
always return string types and converting from hex should always return
bytes.
IMO there is no meaning of bytes as an output of hexlify, since the output
is a
representation of other bytes.
This is also the suggested behavior of bytes.hex in PEP 358
Problems #4 and #5 call for a decision about the input and output of the
functions being discussed:
Option A : Strict input and output
unhexlify (and bytes.fromhex) may only receives string and may only return
bytes
hexlify (and bytes.hex) may only receives bytes and may only return strings
Option B : Robust input and strict output
unhexlify (and bytes.fromhex) may receive bytes and strings and may only
return bytes
hexlify (and bytes.hex) may receive bytes or strings and may only return
strings
Of course we may also consider a third option, which will allow the return
type of
all functions to be robust (perhaps specified in a keyword argument), but as
I wrote in
the description of problem #5, I see no sense in that.
Note that PEP 3137 describes: "... the more strict definitions of encoding
and decoding in
Python 3000: encoding always takes a Unicode string and returns a bytes
sequence, and decoding
always takes a bytes sequence and returns a Unicode string." - suggesting
option A.
To repeat problems #4 and #5, the current behavior does not match any
option:
* The return type of binascii.hexlify should be string, and this is not the
current behavior.
As for the input:
* Option A is not the current behavior because binascii.unhexlify may
receive both input types.
* Option B is not the current behavior because bytes.fromhex does not allow
bytes as input.
To fix these issues, three changes should be applied:
1. Deprecate bytes.fromhex. This fixes the following problems:
#4 (go with option B and remove the function that does not allow bytes
input)
#2 (the binascii functions will be the only way to "do it")
#1 (bytes.hex should not be implemented)
2. In order to keep the functionality that bytes.fromhex has over unhexlify,
the latter function should be able to handle spaces in its input (fix #3)
3. binascii.hexlify should return string as its return type (fix #5)
Hello,
This is a follow-up of the Pycon summit + sprints on packaging.
This is what we have planned to do:
1. refactor distutils in a new standalone version called distutils2
[this is done already and we are actively working in the code]
2. completely revert distutils in Lib/ and Doc/ so the code + doc is
the same than the current 2.6.x branch
3. leave the new sysconfig module, that is used by the Makefile and
the site module
The rest of the work will happen in distutils2 and we will try to
release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the
goal
is to put it back in the stdlib in Python 3.3
Distutils in Python will be feature-frozen and I will only do bug
fixes there. All feature requests will be redirected to Distutils2.
I think the easiest way to manage this for me and for the feedback of
the community is to add in bugs.python.org a "Distutils2" component,
so I can
start to reorganize the issues in there and reassign new issues to
Distutils2 when it applies.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
On Feb 03, 2010, at 12:42 PM, Brett Cannon wrote:
>So what happens when only bytecode is present?
We discussed this at Pycon and agreed that we will not support source-less
deployments by default. The source file must exist or it will be an
ImportError.
This does not mean source-less deployments are not possible though. To
support this use case, you'd have to write a custom import hook. We may write
one as part of the PEP 3147 implementation. Contributions are of course
welcome!
-Barry
Hi All,
Recently some discussion began in the issue 3132 thread (
http://bugs.python.org/issue3132) regarding
implementation of the new struct string syntax for PEP 3118. Mark Dickinson
suggested that I bring the discussion on over to Python Dev. Below is a
summary
of the questions\comments from the thread.
Unpacking a long-double
===================
1. Should this return a Decimal object or a ctypes 'long double'?
2. Using ctypes 'long double' is easier to implement, but precision is
lost when needing to do arithmetic, since the value for cytpes 'long
double'
is converted to a Python float.
3. Using Decimal keeps the desired precision, but the implementation would
be non-trivial and architecture specific (unless we just picked a
fixed number of bytes regardless of the architecture).
4. What representation should be used for standard size and alignment?
IEEE 754 extended double precision?
Pointers
======
1. What is a specific pointer? For example, is '&d' is a pointer to a
double?
2. How would unpacking a pointer to a Python Object work out? Given an
address how would the appropriate object to be unpacked be determined?
3. Can pointers be nested, e.g. '&&d' ?
4. For the 'X{}' format (pointer to a function), is this supposed to mean a
Python function or a C function?
String Syntax
==========
The syntax seems to have transcended verbal description. I think we
need to put forth a grammar. There are also some questions regarding
nesting
levels and mixing specifiers that could perhaps be answered more clearly by
having a grammar:
1. What nesting level can structures have? Arbitrary?
2. The new array syntax claims "multi-dimensional array of whatever
follows".
Truly whatever? Arrays of structures? Arrays of pointers?
3. How do array specifiers and pointer specifiers mix? For example,
would '(2, 2)&d' be a two-by-two array of pointers to doubles?
What about '&(2, 2)d'? Is this a pointer to an two-by-two array of
doubles?
An example grammar is contained in a diff against the PEP attached to this
mail. NOTE: I am *not* actually submitting a patch against the PEP. This
was just the clearest way to present the example grammar.
Use Cases
========
1. What are the real world use cases for these struct string extensions?
These should be fleshed out and documented.
-- Meador
Hello,
On November 2006 and September 2007 Fredrik proposed to update "xml.etree" in
Python 2.6 with the upcoming version 1.3.
Now we are three years later, and the version shipped with 2.7alpha3 is 1.2.6.
http://bugs.python.org/issue1602189#msg54944http://bugs.python.org/issue1143
This would not be an issue, without the numerous bug reports accumulating on
bugs.python.org. Most of these reports are waiting for the 1.3 release.
Three months ago I worked on some of these issues, and after fixing them
separately, I proposed a patch which merges the latest 1.3 snapshot (released in
2007) within the standard library. The aim is to provide a bug-free version of
ElementTree/cElementTree in the standard library.
For this purpose, I grew the test suite from 300 lines to 1800 lines, using both
the tests from upstream and the tests proposed by Neil Muller on issue #6232. To
ensure consistency, now the test_suite for the C implementation is the same as
the Python implementation.
http://bugs.python.org/issue6472
We are still interested with the upcoming release of ElementTree, but we should
adopt a pragmatic approach: the xml.etree.ElementTree needs to be fixed for all
Python users, even if 1.3 is not ready before 2.7beta. This is the only purpose
of the patch.
The patch sticks as much as possible to the upstream library. Initially I kept
all the new features of the 1.3 branch in the patch.
It should ease the integration of 1.3 final when it is released.
With the last comment from Fredrik, I think to be more conservative: I plan to
split out the experimental C API from the package. It is not required for the
bug-fix release, and there's some risk of incompatibility with the final design
of the API, which is still secret.
As a side-effect, the patch will add some features and methods from the 1.3
branch (some of them where requested in the bug tracker):
- ET.fromstringlist(), ET.tostringlist()
- Element.extend(), Element.iter(), Element.itertext()
- new selector engine
- extended slicing
However the highlighted features of this patch are:
- to fix many bugs which were postponed because of 1.3 release
- to ensure consistency between C and Python implementations (with tests)
- to provide a better test coverage
The patch is uploaded on Rietveld for review.
The 3.x version of the patch will be updated after 2.x is merged in trunk.
The patch covers documentation, too.
http://codereview.appspot.com/207048/show
It's time to comment and review.
The proposed plan is to merge the patch in trunk before 2.7 alpha4.
Best regards,
--
Florent Xicluna
Hi,
pysandbox is a new Python sandbox project under development. By default,
untrusted code executed in the sandbox cannot modify the environment (write a
file, use print or import a module). But you can configure the sandbox to
choose exactly which features are allowed or not, eg. import sys module and
read the file /etc/issue.
Website: http://github.com/haypo/pysandbox/
Download the repository using git:
git clone git://github.com/haypo/pysandbox.git
or
git clone http://github.com/haypo/pysandbox.git
Or download the .zip or .tar.gz tarball using the "Download source" button on
the website.
I think that the project reached the "testable" stage. I launch a new
challenge: try to escape from the sandbox. I'm unable to write strict rules.
The goal is to access objects outside the sandbox. Eg. write into a file,
import a module which is not in the whitelist, modify an object outside the
sandbox, etc.
To test the sandbox, you have 3 choices:
- interpreter.py: interactive interpreter executed in the sandbox, use:
--verbose to display the whole sandbox configuration,
--features=help to enable help() function,
--features=regex to enable regex,
--help to display the help.
- execfile.py <your_script.py>: execute your script in the sandbox.
It has also --features option: use --features=stdout to be able
to use the print instruction :-)
- use directly the Sandbox class: use methods call(), execute()
or createCallback()
Don't use "with sandbox: ..." because there is known but with local frame
variables. I think that I will later drop this syntax because of this bug.
Except of debug_sandbox, I consider that all features are safe and so you can
enable all features :-)
There is no prize, it's just for fun! But I will add the name of hackers
founding the best exploits.
pysandbox is not ready for production, it's under heavy development. Anyway I
*hope* that you will quickly find bugs!
--
Use tests.py to found some examples of how you can escape a sandbox. pysandbox
is protected against all methods described in tests.py ;-)
See the README file to get more information about how pysandbox is implemented
and get a list of other Python sandboxes.
pysandbox is currently specific to CPython, and it uses some ugly hacks to
patch CPython in memory. In the worst case it will crash the pysandbox Python
process, that's all. I tested it under Linux with Python 2.5 and 2.6. The
portage to Python3 is not done yet (is someone motivated to write a
patch? :-)).
--
Victor Stinner
http://www.haypocalc.com/
