Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Phillip J. Eby]

At 05:26 PM 9/27/2006 -0700, Brett Cannon wrote:
>Ah, OK.  So for importing 'email', the zipimporter would call the .pyc 
>importer and it would ask the zipimporter, "can you get me email.pyc?" and 
>if it said no it would move on to asking the .py importer for email.py, etc.

Yes, exactly.


>That's fine.  Just thinking about how the current situation sucks for NFS 
>but how caching just isn't done.  But obvoiusly this could change.

Well, with this design, you can have a CachingFilesystemImporter as your 
storage mechanism to speed things up.


>> >>Of course, to fully support .pyc timestamp checking and writeback, you'd
>> >>need some sort of "stat" or "getmtime" feature on the parent importer, as
>> >>well as perhaps an optional "save_data" method.  These would be extensions
>> >>to PEP 302, but welcome ones.
>> >
>> >Could pass the string representing the location of where the string came
>> >from.  That would allow for the required stat calls for .pyc files as
>> >needed without having to implement methods just for this one use case.
>>
>>Huh?  In order to know if a .pyc is up to date, you need the st_mtime of
>>the .py file.  That can't be done in the parent importer without giving it
>>format knowledge, which goes against the point of the exercise.
>
>Sorry, thought .pyc files based whether they needed to be recompiled based 
>on the stat info on the .py and .pyc file, not on data stored from within 
>the .pyc .

It's not just that (although I believe it's also the case that there is a 
timestamp inside .pyc), it's that to do the check in the parent importer, 
the parent importer would have to know that there is such a thing as 
.py-and-.pyc.  The whole point of this design is that the parent importer 
doesn't have to know *anything* about filename extensions OR how those 
files are formatted internally.  In this scheme, adding more child 
importers is sufficient to add all the special handling needed for 
.py/.pyc-style schemes.

Of course, for maximum flexibility, you might want get_stream() and 
get_file() methods optionally available, since a .so loader really needs a 
file, and .pyc might want to read in two stages.  But the child importers 
can be defensively coded so as to be able to live with only a 
parent.get_data(), if necessary, and do the enhanced behaviors only if 
stat() or get_stream() or write_data() etc. attributes are available on the 
parent.

If we get some standards for these additional attributes, we can document 
them as standard PEP 302 extensions.

The format importer mechanism might want to have something like 
'sys.import_formats' as a list of importer classes (or factories).  Parent 
(storage) importer classes would then create instances to use.

If you add a new format importer to sys.import_formats, you would of course 
need to clear sys.path_importer_cache, so that the individual importers are 
rebuilt on the next import, and thus they will create new child importer 
chains.

Yeah, that pretty much ought to do it.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Brett Cannon]

On 9/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 04:11 PM 9/27/2006 -0700, Brett Cannon wrote:>On 9/27/06, Phillip J. Eby><[EMAIL PROTECTED]>[EMAIL PROTECTED]
> wrote:>>At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote:>> >But it has been suggested here that the import machinery be rewritten in>> >Python.  Now I have never touched the import code since it has always had
>> >the reputation of being less than friendly to work with.  I am asking for>> >opinions from people who have worked with the import machinery before if>> >it is so bad that it is worth trying to re-implement the import semantics
>> >in pure Python or if in the name of time to just work with the C>> >code.  Basically I will end up breaking up built-in, .py, .pyc, and>> >extension modules into individual importers and then have a chaining class
>> >to act as a combined .pyc/.py combination importer (this will also make>> >writing out to .pyc files an optional step of the .py import).The problem you would run into here would be supporting zip imports.
>>I have not looked at zipimport so I don't know the exact issue in terms of>how it hooks into the import machinery.  But a C level API will most>likely be needed.I was actually assuming you planned to reimplement that in Python as well,
and hence the need for the storage/format separation.I was not explictly planning on it. 
>>   It>>would probably be more useful to have a mapping of file types to "format>>handlers", because then a filesystem importer or zip importer would then be>>able to work with any .py/.pyc/.pyo/whatever formats, along with any new
>>ones that are invented, without reinventing the wheel.>>So you are saying the zipimporter would then pull out of the zip file the>individual file to import and pass that to the format-specific importer?
No, I'm saying that the zipimporter would simply call the format importersin sequence, as in your original concept.  However, these importers wouldcall *back* to the zipimporter to ask if the file they are looking for is
there.Ah, OK.  So for importing 'email', the zipimporter would call the .pyc importer and it would ask the zipimporter, "can you get me email.pyc?" and if it said no it would move on to asking the .py importer for 
email.py, etc.>>Thus, whether it's file import, zip import, web import, or whatever, the
>>same handlers would be reusable, and when people invent new extensions like>>.ptl, .kid, etc., they can just register format handlers instead.>>So a sepration of data store from data interpretation for importation.  My
>only worry is a possible explosion of checks for the various data>types.  If you are using the file data store and had .py, .pyc, .so,>module.so , .ptl, and .kid registered that might suck in terms of
>performance hit.Look at it this way: the parent importer can always pull a directorylisting once and cache it for the duration of its calls to the childimporters.  In practice, however, I suspect that the stat calls will be
faster.  In the case of a zipimport parent, the zip directory is alreadycached.Also, keep in mind that most imports will likely occur *before* any specialadditional types get registered, so the hits will be minimal.  And the more
of sys.path is taken up by zip files, the less of a hit it will be for eachquery.That's fine.  Just thinking about how the current situation sucks for NFS but how caching just isn't done.  But obvoiusly this could change. 
>   And I am assuming for a web import that it would decide based on the
> extension of the resulting web address?No - you'd effectively end up doing a web hit for each possibleextension.  Which would suck, but that's what caching isfor.  Realistically, you wouldn't want to do web-based imports without some
disk-based caching anyway.>   And checking for the various types might not work well for other data> store types.  Guess you would need a way to register with the data store> exactly what types of data interpretation you might want to check.
No, you just need a method on the parent importer like get_data().>Other option is to just have the data store do its magic and somehow know>what kind of data interpretation is needed for the string returned (
e.g.,>a database data store might implicitly only store .py code and thus know>that it will only return a string of source).  Then that string and the>supposed file extension is passed ot the next step of creating a module
>from that data string.Again, all that's way more complex than you need; you can do the same thingby just raising IOError from get_data() when asked for something that's nota .py.>>Format handlers could of course be based on the PEP 302 protocol, and
>>simply accept a "parent importer" with a get_data() method.  So, let's say>>you have a PyImporter:  class PyImporter:>>  def __init__(self, parent_importer):
>>  self.parent = parent_importer  def find_module(self, fullname):>>  path = fullname.split('.')[-1]+'.py'>> 

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Phillip J. Eby]

At 04:11 PM 9/27/2006 -0700, Brett Cannon wrote:


>On 9/27/06, Phillip J. Eby 
><[EMAIL PROTECTED]> wrote:
>>At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote:
>> >But it has been suggested here that the import machinery be rewritten in
>> >Python.  Now I have never touched the import code since it has always had
>> >the reputation of being less than friendly to work with.  I am asking for
>> >opinions from people who have worked with the import machinery before if
>> >it is so bad that it is worth trying to re-implement the import semantics
>> >in pure Python or if in the name of time to just work with the C
>> >code.  Basically I will end up breaking up built-in, .py, .pyc, and
>> >extension modules into individual importers and then have a chaining class
>> >to act as a combined .pyc/.py combination importer (this will also make
>> >writing out to .pyc files an optional step of the .py import).
>>
>>The problem you would run into here would be supporting zip imports.
>
>I have not looked at zipimport so I don't know the exact issue in terms of 
>how it hooks into the import machinery.  But a C level API will most 
>likely be needed.

I was actually assuming you planned to reimplement that in Python as well, 
and hence the need for the storage/format separation.


>>   It
>>would probably be more useful to have a mapping of file types to "format
>>handlers", because then a filesystem importer or zip importer would then be
>>able to work with any .py/.pyc/.pyo/whatever formats, along with any new
>>ones that are invented, without reinventing the wheel.
>
>So you are saying the zipimporter would then pull out of the zip file the 
>individual file to import and pass that to the format-specific importer?

No, I'm saying that the zipimporter would simply call the format importers 
in sequence, as in your original concept.  However, these importers would 
call *back* to the zipimporter to ask if the file they are looking for is 
there.


>>Thus, whether it's file import, zip import, web import, or whatever, the
>>same handlers would be reusable, and when people invent new extensions like
>>.ptl, .kid, etc., they can just register format handlers instead.
>
>So a sepration of data store from data interpretation for importation.  My 
>only worry is a possible explosion of checks for the various data 
>types.  If you are using the file data store and had .py, .pyc, .so, 
>module.so , .ptl, and .kid registered that might suck in terms of 
>performance hit.

Look at it this way: the parent importer can always pull a directory 
listing once and cache it for the duration of its calls to the child 
importers.  In practice, however, I suspect that the stat calls will be 
faster.  In the case of a zipimport parent, the zip directory is already 
cached.

Also, keep in mind that most imports will likely occur *before* any special 
additional types get registered, so the hits will be minimal.  And the more 
of sys.path is taken up by zip files, the less of a hit it will be for each 
query.


>   And I am assuming for a web import that it would decide based on the 
> extension of the resulting web address?

No - you'd effectively end up doing a web hit for each possible 
extension.  Which would suck, but that's what caching is 
for.  Realistically, you wouldn't want to do web-based imports without some 
disk-based caching anyway.

>   And checking for the various types might not work well for other data 
> store types.  Guess you would need a way to register with the data store 
> exactly what types of data interpretation you might want to check.

No, you just need a method on the parent importer like get_data().


>Other option is to just have the data store do its magic and somehow know 
>what kind of data interpretation is needed for the string returned (e.g., 
>a database data store might implicitly only store .py code and thus know 
>that it will only return a string of source).  Then that string and the 
>supposed file extension is passed ot the next step of creating a module 
>from that data string.

Again, all that's way more complex than you need; you can do the same thing 
by just raising IOError from get_data() when asked for something that's not 
a .py.


>>Format handlers could of course be based on the PEP 302 protocol, and
>>simply accept a "parent importer" with a get_data() method.  So, let's say
>>you have a PyImporter:
>>
>>  class PyImporter:
>>  def __init__(self, parent_importer):
>>  self.parent = parent_importer
>>
>>  def find_module(self, fullname):
>>  path = fullname.split('.')[-1]+'.py'
>>  try:
>>  source = self.parent.get_data(path)
>>  except IOError:
>>  return None
>>  else:
>>  return PySourceLoader(source)
>>
>>See what I mean?  The importers and loaders thus don't have to do direct
>>filesystem operations.
>
>I think so.  Basically you w

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Brett Cannon]

On 9/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote:>But it has been suggested here that the import machinery be rewritten in>Python.  Now I have never touched the import code since it has always had>the reputation of being less than friendly to work with.  I am asking for
>opinions from people who have worked with the import machinery before if>it is so bad that it is worth trying to re-implement the import semantics>in pure Python or if in the name of time to just work with the C
>code.  Basically I will end up breaking up built-in, .py, .pyc, and>extension modules into individual importers and then have a chaining class>to act as a combined .pyc/.py combination importer (this will also make
>writing out to .pyc files an optional step of the .py import).The problem you would run into here would be supporting zip imports.I have not looked at zipimport so I don't know the exact issue in terms of how it hooks into the import machinery.  But a C level API will most likely be needed.
  Itwould probably be more useful to have a mapping of file types to "format
handlers", because then a filesystem importer or zip importer would then beable to work with any .py/.pyc/.pyo/whatever formats, along with any newones that are invented, without reinventing the wheel.
So you are saying the zipimporter would then pull out of the zip file the individual file to import and pass that to the format-specific importer?
Thus, whether it's file import, zip import, web import, or whatever, thesame handlers would be reusable, and when people invent new extensions like.ptl, .kid, etc., they can just register format handlers instead.
So a sepration of data store from data interpretation for importation.  My only worry is a possible explosion of checks for the various data types.  If you are using the file data store and had .py, .pyc, .so, module.so
, .ptl, and .kid registered that might suck in terms of performance hit.  And I am assuming for a web import that it would decide based on the extension of the resulting web address?  And checking for the various types might not work well for other data store types.  Guess you would need a way to register with the data store exactly what types of data interpretation you might want to check.
Other option is to just have the data store do its magic and somehow know what kind of data interpretation is needed for the string returned (e.g., a database data store might implicitly only store .py code and thus know that it will only return a string of source).  Then that string and the supposed file extension is passed ot the next step of creating a module from that data string.
Format handlers could of course be based on the PEP 302 protocol, andsimply accept a "parent importer" with a get_data() method.  So, let's say
you have a PyImporter: class PyImporter: def __init__(self, parent_importer): self.parent = parent_importer def find_module(self, fullname): path = 
fullname.split('.')[-1]+'.py' try: source = self.parent.get_data(path) except IOError: return None else: return PySourceLoader(source)
See what I mean?  The importers and loaders thus don't have to do directfilesystem operations.I think so.  Basically you want more of a way to stack imports so that the basic importers are just passed the string of what it is supposed to load from.  Other importers higher in the chain can handle getting that string.
Of course, to fully support .pyc timestamp checking and writeback, you'dneed some sort of "stat" or "getmtime" feature on the parent importer, as
well as perhaps an optional "save_data" method.  These would be extensionsto PEP 302, but welcome ones.Could pass the string representing the location of where the string came from.  That would allow for the required stat calls for .pyc files as needed without having to implement methods just for this one use case.
Anyway, based on my previous work with pkg_resource, pkgutil, zipimport,import.c
, etc. I would say this is how I'd want to structure areimplementation of the core system.  And if it were for Py3K, I'd probablytreat sys.path and all the import hooks associated with it as a singlemeta-importer on 
sys.meta_path -- listed after a meta-importer for handlingfrozen and built-in modules.  (I.e., the meta-importer that uses sys.pathand its path hooks would be last on sys.meta_path.)Ah, interesting idea!  Could even go as far as removing 
sys.path and just making it an attribute of the base importer if you really wanted to make it just meta_path for imports.
In other words, sys.meta_path is really the only critical import hook fromthe raw interpreter's point of view.  sys.path, however, (along withsys.path_hooks and sys.path_importer_cache) is critical from theperspective of users, applications, etc., as there has to be some way to
get things onto Python's path in the 

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Phillip J. Eby]

At 02:11 PM 9/27/2006 -0700, Brett Cannon wrote:
>But it has been suggested here that the import machinery be rewritten in 
>Python.  Now I have never touched the import code since it has always had 
>the reputation of being less than friendly to work with.  I am asking for 
>opinions from people who have worked with the import machinery before if 
>it is so bad that it is worth trying to re-implement the import semantics 
>in pure Python or if in the name of time to just work with the C 
>code.  Basically I will end up breaking up built-in, .py, .pyc, and 
>extension modules into individual importers and then have a chaining class 
>to act as a combined .pyc/.py combination importer (this will also make 
>writing out to .pyc files an optional step of the .py import).

The problem you would run into here would be supporting zip imports.  It 
would probably be more useful to have a mapping of file types to "format 
handlers", because then a filesystem importer or zip importer would then be 
able to work with any .py/.pyc/.pyo/whatever formats, along with any new 
ones that are invented, without reinventing the wheel.

Thus, whether it's file import, zip import, web import, or whatever, the 
same handlers would be reusable, and when people invent new extensions like 
.ptl, .kid, etc., they can just register format handlers instead.

Format handlers could of course be based on the PEP 302 protocol, and 
simply accept a "parent importer" with a get_data() method.  So, let's say 
you have a PyImporter:

 class PyImporter:
 def __init__(self, parent_importer):
 self.parent = parent_importer

 def find_module(self, fullname):
 path = fullname.split('.')[-1]+'.py'
 try:
 source = self.parent.get_data(path)
 except IOError:
 return None
 else:
 return PySourceLoader(source)

See what I mean?  The importers and loaders thus don't have to do direct 
filesystem operations.

Of course, to fully support .pyc timestamp checking and writeback, you'd 
need some sort of "stat" or "getmtime" feature on the parent importer, as 
well as perhaps an optional "save_data" method.  These would be extensions 
to PEP 302, but welcome ones.

Anyway, based on my previous work with pkg_resource, pkgutil, zipimport, 
import.c, etc. I would say this is how I'd want to structure a 
reimplementation of the core system.  And if it were for Py3K, I'd probably 
treat sys.path and all the import hooks associated with it as a single 
meta-importer on sys.meta_path -- listed after a meta-importer for handling 
frozen and built-in modules.  (I.e., the meta-importer that uses sys.path 
and its path hooks would be last on sys.meta_path.)

In other words, sys.meta_path is really the only critical import hook from 
the raw interpreter's point of view.  sys.path, however, (along with 
sys.path_hooks and sys.path_importer_cache) is critical from the 
perspective of users, applications, etc., as there has to be some way to 
get things onto Python's path in the first place.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

[Brett Cannon]

I am at the point with my security work that I need to consider how I am going to restrict importing modules.  My current plan is to basically implement phase 2 of PEP 302 and control imports through what importer objects are provided.  This work should lead to a meta_path importer for built-ins and then path_hooks importers for .py, .pyc, and extension modules.
But it has been suggested here that the import machinery be rewritten in Python.  Now I have never touched the import code since it has always had the reputation of being less than friendly to work with.  I am asking for opinions from people who have worked with the import machinery before if it is so bad that it is worth trying to re-implement the import semantics in pure Python or if in the name of time to just work with the C code.  Basically I will end up breaking up built-in, .py, .pyc, and extension modules into individual importers and then have a chaining class to act as a combined .pyc/.py combination importer (this will also make writing out to .pyc files an optional step of the .py import).
Any opinions would be greatly appreciated on this.  I need to get back to my supervisor by the end of the day Friday with a decision as to whether I think it is worth the rewrite.  If you are interested in helping with the Python rewrite (or in general if the work is done with the C code), please let me know since if enough people want to help with the Python rewrite it might help wash out the extra time needed to make it work.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minipython

[Gustavo Niemeyer]

> I would like to run Python scripts on an embedded MIPS Linux platform
> having only 2 MiB of flash ROM and 16 MiB of RAM for everything.
(...)

Have you looked at Python for S60 and Python for the Maemo platform?

If not directly useful, they should provide some hints.

[1] http://opensource.nokia.com/projects/pythonfors60/
[2] http://pymaemo.sf.net

-- 
Gustavo Niemeyer
http://niemeyer.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] List of candidate 2.4.4 bugs?

[Martin v. Löwis]

A.M. Kuchling schrieb:
> One reason I often don't backport a bug is because I'm not sure if
> there will be another bugfix release; if not, it's wasted effort, and
> I wasn't sure if a 2.4.4 release was ever going to happen.  After
> 2.4.4, will there be a 2.4.5 or is that too unlikely?

The "tradition" seems to be that there will be one last bug fix release
after a feature release is made; IOW, two branches are always maintained
(the trunk and the last release). Following this tradition, there
wouldn't be another 2.4.x release (and I think Anthony already said so).
Likewise, 2.5. will be maintained until 2.6 is released, and one last
2.5.x release will be made shortly after 2.6.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] openssl - was: 2.4.4c1 October 11, 2.4.4 final October 18

[Martin v. Löwis]

Jim Jewett schrieb:
> OpenSSL should probably be upgraded to 0.9.8.c (or possibly 0.9.7.k)
> because of the security patch.
> 
>http://www.openssl.org/
>http://www.openssl.org/news/secadv_20060905.txt
> 
> I'm not sure which version shipped with the 2.4 windows binaries, but
> externals (for 2.5) still points to 0.9.8.a, which is vulnerable.

If there is any change, it should be to 0.9.7k; we shouldn't switch to
a new "branch" of OpenSSL in micro releases.

However, I'm uncertain whether I can do the update in next weeks.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] openssl - was: 2.4.4c1 October 11, 2.4.4 final October 18

[Jim Jewett]

OpenSSL should probably be upgraded to 0.9.8.c (or possibly 0.9.7.k)
because of the security patch.

http://www.openssl.org/
http://www.openssl.org/news/secadv_20060905.txt

I'm not sure which version shipped with the 2.4 windows binaries, but
externals (for 2.5) still points to 0.9.8.a, which is vulnerable.

openssl has also patched 0.9.7.k (0.9.7 was released in 2003) and the
patch itself

http://www.openssl.org/news/patch-CVE-2006-4339.txt

should apply to 0.9.6 (released in 2000).

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18

[skip]

Fredrik> [EMAIL PROTECTED] wrote:
>> I think the right thing is for InteractiveConsole to dup
>> sys.std{in,out,err} and do its own thing for its raw_input() method
>> instead of naively calling the raw_input() builtin.

Fredrik> what guarantees that sys.stdin etc has a valid and dup:able
Fredrik> fileno when the console is instantiated ?

Nothing, I suppose.  I'm just concerned that the InteractiveConsole instance
keep working after its interact() method is called.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18

[Fredrik Lundh]

[EMAIL PROTECTED] wrote:

> I think the right thing is for InteractiveConsole to dup sys.std{in,out,err}
> and do its own thing for its raw_input() method instead of naively calling
> the raw_input() builtin.

what guarantees that sys.stdin etc has a valid and dup:able fileno when 
the console is instantiated ?



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] List of candidate 2.4.4 bugs?

[A.M. Kuchling]

On Wed, Sep 27, 2006 at 06:56:14PM +0200, "Martin v. Löwis" wrote:
> I don't think so. Also, I see little chance that many bugs will be fixed
> that aren't already. People should really do constant backporting,
> instead of starting backports when a subminor release is made.

Agreed.  

One reason I often don't backport a bug is because I'm not sure if
there will be another bugfix release; if not, it's wasted effort, and
I wasn't sure if a 2.4.4 release was ever going to happen.  After
2.4.4, will there be a 2.4.5 or is that too unlikely?

I've done an 'svn log' on the modules I'm familiar with (curses, zlib,
gzip) and will look at backporting the results.

Grepping for 'backport candidate' in 'svn log -r37910:HEAD' turns up
30-odd checkins that contain the phrase:

r51728 r51669 r47171 
r47061 r46991 r46882 r46879
r46878 r46602
r46589 r45234 r41842
r41696 r41531 r39767 r39743 r39739 r39650
r39645
r39595 r39594 r39491
r39135 r39044 r39030 r39012 r38932
r38927 r38887 
r38826 r38781
r38772 r38745

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] List of candidate 2.4.4 bugs?

[Martin v. Löwis]

A.M. Kuchling schrieb:
> Is anyone maintaining a list of candidate bugs to be fixed in 2.4.4?

I don't think so. Also, I see little chance that many bugs will be fixed
that aren't already. People should really do constant backporting,
instead of starting backports when a subminor release is made.

Of course, there are some things that people remember and want to see
fixed, but they are pretty arbitrary.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] List of candidate 2.4.4 bugs?

[A.M. Kuchling]

Is anyone maintaining a list of candidate bugs to be fixed in 2.4.4?
If not, should we start a wiki page for the purpose?

--amk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [SECUNIA] "buffer overrun in repr() for unicode strings" Potential Vulnerability (fwd)

[skip]

This came in to the webmaster address and was also addressed to a number of
individuals (looks like the SF project admins).  This appears like it would
be of general interest to this group.

Looking through this message and the various bug tracker items it's not
clear to me if Secunia wants to know if the patch (which I believe has
already been applied to all three active svn branches) is the source of the
problem or if they want to know if it solves the buffer overrun problem.
Are they suggesting that 10*size should be the character multiple in all
cases?

Skip

--- Begin Message ---
Hi,

We are currently evaluating a buffer overflow in the repr() function in
the handling of Unicode strings in Python:
http://sourceforge.net/tracker/index.php?aid=1541585&group_id=5470&atid=305470&func=detail
https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208162
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208166

According to Red Hat this has been assigned CVE-2006-4980 and has been
marked as having a security impact. We would appreciate your comments on
the issue. Who and how could this be exploited and are there any
mitigating factors? Can this be exploited by an application (e.g. a CGI
script) which takes input from untrusted sources, transforms the input
into a UTF-32 string, and then calls repr() with it, to execute
arbitrary code?

Thank you in advance.

-- 
Kind regards,

Andreas Sandblad
IT Security Specialist

Secunia
Hammerensgade 4, 2. floor
DK-1267 Copenhagen K
Denmark

Tlf.: +45 7020 5144
Fax:  +45 7020 5145
--- End Message ---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18

[skip]

Anthony> If you know of any backports that should go in, please make
Anthony> sure you get them done before the 11th.

skip> John Hunter (matplotlib author) recently made me aware of a
skip> problem with code.InteractiveConsole.  It doesn't protect itself
skip> from the user closing sys.stdout:

...

I attached a patch for code.py to

http://sourceforge.net/support/tracker.php?aid=1563079

If someone wants to take a peek, that would be appreciated.  It seems to me
that it certainly should go into 2.5.1 and 2.6.  Whether it's deemed serious
enough to go into 2.4.4 is another question.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com