Re: [Python-Dev] Python security team
Brett Cannon wrote: > On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I would like to know if a Python security team does exist. I sent an email >> about an imageop issue, and I didn't get any answer. Later I learned that a >> security ticket was created, I don't have access to it. >> > > Yes, the PSRT (Python Security Response Team) does exist. We did get > your email; sorry we didn't respond. There are very few members on > that list and most of them are extremely busy. Responding to your > email just slipped through the cracks. I believe Benjamin was the last > person to work on your submitted patch. > [...] If we don't have a documented procedure, or if we do have a procedure and it isn't being followed, we can't be said to be taking security seriously, which I would find disappointing. This is one of the few areas where we probably *do* need to be meticulous, and the absence of a reply to a security report isn't really satisfactory. Perhaps if the PSF does eventually hire some paid help, running the secretarial and administrative portions of the security team would help the busy members to avoid such issues dropping through the cracks in future. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python security team
Le Sunday 28 September 2008 02:45:14 Brett Cannon, vous avez écrit : > > Second, I would like to help to fix all Python security issues. It looks > > like Python community isn't very reactive (proactive?) about security. > > Eg. a DoS was reported in smtpd server (integrated to Python)... 15 > > months ago. A patch is available but it's not applied in Python trunk. > > Historically we have not been proactive. Well, I just asked to know the current status. First step for a secure program is to know its limits ;) > Nope. I think my paper and blog posts are about the best you are going > to find I will try to write a document about Python and security next week. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?
Le Saturday 27 September 2008 19:41:50 Martin v. Löwis, vous avez écrit : > > I think that the problem is important because it's a regression from 2.5 > > to 2.6/3.0. Python 2.5 uses bytes filename, so it was possible to > > open/unlink "invalid" unicode strings (since it's not unicode but bytes). > > I'd like to stress that the problem is *not* a regression from 2.5 to 2.6. Sorry, 2.6 has no problem. This issue is a regression from Python2 to Python3. > Even though you may run into file names that can't be decoded, > that happening really indicates some bigger problem in the management > of the system where this happens, and the proper solution (IMO) should > be to change the system In the *real world*, people are using different file systems, different operations systems, and some broken programs and/or operating system create invalid filenames. It could be a configuration problem (wrong charset definition in /etc/fstab) or the charset autodetection failure, but who cares? Sometimes you don't care that your music directory contains some strange filenames, you just want to hear the music. Or maybe you would like to *fix* the encoding problem, which is not possible using Python3 trunk. People having this problem are, for example, people who write or use a backup program. This week someone asked me (on IRC) how to manage filenames in pure unicode with python 2.5 and Linux... which was impossible because on of his filename was invalid (maybe a file from a Windows system). So he switched to raw (bytes) filenames. In a perfect world, everybody uses Linux with utf-8 filenames and only programs in Python using space indentation :-D -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?
On 9/27/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> I think that the problem is important because it's a regression from 2.5 >> to >> 2.6/3.0. Python 2.5 uses bytes filename, so it was possible to >> open/unlink "invalid" unicode strings (since it's not unicode but bytes). > > I'd like to stress that the problem is *not* a regression from 2.5 to 2.6. > > As for 3.0, I'd like to argue that the problem is a minor issue. Even > though you may run into file names that can't be decoded, that happening > really indicates some bigger problem in the management of the system > where this happens, and the proper solution (IMO) should be to change > the system (leaving open the question whether or not Python should > be also changed to work with such broken systems). > > Regards, > Martin Note: bcc python-dev,cc: python-3000 "broken" systems will always exist. Code to deal with them must be possible to write in python 3.0. since any given path (not just fs) can have its own encoding it makes the most sense to me to let the OS deal with the errors and not try to enforce bytes vs string encoding type at the python lib. level. -gps ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Filename as byte string in python 2.6 or 3.0?
> I can't agree here. File handling is a fundamental operation and I
> would expect something like:
>
for fname in os.listdir('.'):
> ... if os.path.isfile(fname):
> ... file(fname)
>
> to work for all files.
I agree. However, if it fails: is the bug of the Python, or of the
system administrator maintaining it?
> To have to know to put in special handling for
> certain corner case filenames or worse to not be able to open some
> files at all would be a serious loss. It would also complicate
> migrating code correctly to 3.0.
I agree completely. Unfortunately, all proposed solutions *do* require
special handling for certain corner cases.
> Regardless of whose fault the underlying issue is, someone has to deal
> with the problem and if core Python doesn't, each developer who
> encounters the problem will have to come up with his/her own solution.
This is quite in the abstract. Can you be more specific?
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python security team
On Sun, Sep 28, 2008 at 6:39 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: >> On Sat, Sep 27, 2008 at 8:54 AM, Victor Stinner >> <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> I would like to know if a Python security team does exist. I sent an email >>> about an imageop issue, and I didn't get any answer. Later I learned that a >>> security ticket was created, I don't have access to it. >>> >> >> Yes, the PSRT (Python Security Response Team) does exist. We did get >> your email; sorry we didn't respond. There are very few members on >> that list and most of them are extremely busy. Responding to your >> email just slipped through the cracks. I believe Benjamin was the last >> person to work on your submitted patch. >> > [...] > > If we don't have a documented procedure, or if we do have a procedure > and it isn't being followed, we can't be said to be taking security > seriously, which I would find disappointing. This is one of the few > areas where we probably *do* need to be meticulous, and the absence of a > reply to a security report isn't really satisfactory. > > Perhaps if the PSF does eventually hire some paid help, running the > secretarial and administrative portions of the security team would help > the busy members to avoid such issues dropping through the cracks in future. > That actually would be extremely beneficial since as right now a big problem we have is writing up the official announcement that some security issue has been plugged and then sticking up the patches online for people to download. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: Python 2.6 final next Wednesday
Barry Warsaw wrote: Once again, I've gone through the release blocker issues and knocked anything that doesn't specifically affect 2.6 to deferred blocker. This leaves us with 7 open blocking issues. I noticed you deferred issue3723. I wonder how this "doesn't affect" 2.6 when it appears I can't even use mod_wsgi (for Apache) with 2.6 if this doesn't get fixed. It's a pretty bad regression, right? Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: Python 2.6 final next Wednesday
On Sun, Sep 28, 2008 at 5:20 PM, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote: > Barry Warsaw wrote: >> >> Once again, I've gone through the release blocker issues and knocked >> anything that doesn't specifically affect 2.6 to deferred blocker. This >> leaves us with 7 open blocking issues. > > I noticed you deferred issue3723. I wonder how this "doesn't affect" 2.6 > when it appears I can't even use mod_wsgi (for Apache) with 2.6 if this > doesn't get fixed. It's a pretty bad regression, right? It doesn't affect 2.6. Only 3.0. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
