Re: [Python-Dev] Other SSL issues in the tracker have been marked
On Sun, 26 Aug 2007, Bill Janssen wrote: > This must be the call to os.system in test_ssl.py:create_cert_files(). > It's very UNIX-y. Can any bi-platform folks suggest a good > alternative to > > os.system( > "openssl req -batch -new -x509 -days 10 -nodes -config %s " > "-keyout \"%s\" -out \"%s\" > /dev/null < /dev/null 2>&1" % > (conffile, crtfile, crtfile)) > > that would be more Windows-friendly? Bundle a cert and key as part of the test? Is there a requirement to use a freshly-minted certificate each time? -d ___ 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] tarfile and directory traversal vulnerability
> GNU tar is not supposed to place files outside its working directory, > unless explicitly specified otherwise. So this is considered a security > vulnerability. So that's a vulnerability in GNU tar, sure - it does something that it is not supposed to do. But why is there also a vulnerability in tarfile.py? It does very well what it is supposed to do. > AFAIK there is no specified behavior and other tars might act > differently. I think you are mistaken here. POSIX specifies something (although I'm uncertain what precisely) for pax(1); this ended the tar wars. > Furthermore, extract() and extractall() documentation says "Extract > (...) from the archive to the *current working directory* or directory > [path]." > So current behavior is actually inconsistent with the documentation. Ok. However, what does it mean to create a file with an absolute path in the current directory? Also, it's fairly easy to see what creating "../foo" should do when done in the current directory: create a sibling of the current directory. > No, the tar file itself is correct, according to POSIX. You can put > anything into a tar. Point is, you should be able to untar any file > 'safely'. I see, you are asking for an option. If people want to have this option, it should be added. Then, of course, the question is what default it should take. 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] Other SSL issues in the tracker have been marked
> On Sun, 26 Aug 2007, Bill Janssen wrote: > > > This must be the call to os.system in test_ssl.py:create_cert_files(). > > It's very UNIX-y. Can any bi-platform folks suggest a good > > alternative to > > > > os.system( > > "openssl req -batch -new -x509 -days 10 -nodes -config %s " > > "-keyout \"%s\" -out \"%s\" > /dev/null < /dev/null 2>&1" % > > (conffile, crtfile, crtfile)) > > > > that would be more Windows-friendly? > > Bundle a cert and key as part of the test? Is there a requirement to > use a freshly-minted certificate each time? > > -d That's what we've done, and it seems to have turned the Ubuntu and Debian buildbots green again. The Windows question is harder, though -- I'm still not seeing a clean buildbot test on Windows. By the way, this solution introduces a Y2K problem into the test code. The included cert runs out in February of 2013, and will need to be regenerated then. Bill ___ 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] Other SSL issues in the tracker have been marked
Looking at the buildbots today, Windows is still unhappy. It seems to
have gotten further, though.
The problematic test is this one:
File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py",
line 77, in testSSLconnect
s.connect(("pop.gmail.com", 995))
File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\ssl.py", line 170, in
connect
if self._sslobj or (self.getsockname()[1] != 0):
File "", line 1, in getsockname
error: (10022, 'Invalid argument')
Looks like a valid complaint, actually. It should probably read
if self._sslobj or (int(getnameinfo(self.getsockname(), 0)[1]) != 0):
where "getnameinfo" is from the socket module. We're trying to see if
the socket has been bound or connected already.
I'm loath to generate a patch till I actually try this on a Windows
machine. So I'm going to try that this afternoon, and generate a new
patch for you.
Bill
___
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
[Python-Dev] test_calendar broken on trunk
On the community trunk buildbots this checkin: 1. Changed by: walter.doerwald Changed at: Tue 28 Aug 2007 16:38:27 Branch: trunk Revision: 57620 Changed files: * trunk/Doc/library/calendar.rst * trunk/Lib/calendar.py Comments: Fix title endtag in HTMLCalender.formatyearpage(). Fix documentation for HTMLCalender.formatyearpage() (there's no themonth parameter). This fixes issue1046. broke test_calendar. Details here: http://www.python.org/dev/buildbot/community/all/ Skip ___ 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
[Python-Dev] Merging a branch, and new docs
Hello everybody. Mark Dickinson helped a lot (*a lot*) with the decimal branch, and we're near to pass the brand new test cases from Cowlishaw. My original idea is to update all the documentation before merging the branch into the trunk, but now that they changed so much, I don't know what to do: - Update all the Doc dir in the branch with the new Doc dir in the trunk, fix the docs, and make the merge. - Merge the branch, and fix the docs directly in the trunk (I promise to fix them months before 2.6a0). Thanks for the advice! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
[Python-Dev] Triage of old tracker bugs: Any use?
I've taken the week off and I'm trying to do something useful for Python in some of my time. I've basically been looking through the entries sorted by priority and least recent activity. Some items I've been able to do something with (like the "immediate" priority %formatting bug #1467929, and the "high" priority bz2 module bug #1597011). Others I've been just kind of prodding people to take some action on, just kind of getting them in front of people again. Keeping them "fresh" instead of just letting them stagnate... I kind of figure that something that's in "high" priority, that has been sitting there for 46 months, either needs to have some activity on it or should be pushed to a lower priority. I've also been tempted to try to triage some of the bugs without assigned priorities, guessing a priority, that sort of thing. Is doing this sort of triage or administration work useful? Any recommendations on what you'd like to have happen in this sort of task? Thanks, Sean -- Obtuse: Not pointed or acute. Exceeding 90 degrees but less than 180 degrees. OOOooh! Rounded at the free end. Dull... Hey! That's an insult! -- WKRP Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ 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] Triage of old tracker bugs: Any use?
On 8/28/07, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > I've taken the week off and I'm trying to do something useful for Python in > some of my time. I've basically been looking through the entries sorted by > priority and least recent activity. > > Some items I've been able to do something with (like the "immediate" > priority %formatting bug #1467929, and the "high" priority bz2 module bug > #1597011). Others I've been just kind of prodding people to take some > action on, just kind of getting them in front of people again. Keeping > them "fresh" instead of just letting them stagnate... > > I kind of figure that something that's in "high" priority, that has been > sitting there for 46 months, either needs to have some activity on it > or should be pushed to a lower priority. > > I've also been tempted to try to triage some of the bugs without assigned > priorities, guessing a priority, that sort of thing. > > Is doing this sort of triage or administration work useful? Any > recommendations on what you'd like to have happen in this sort of task? I think closing off old bugs is helpful. We have 1281 bugs open right now and that is not great. Getting that number down would be useful. If an old bug needs a test, then write the test. If it is no longer valid, just close it. And if it needs more info and prodding from somone, set the status as "Pending" so that if someone who reported it is not bothering to update the info it can be easily closed off if that reply never happens. I would say assigning bugs to the right person is a good thing in hopes of prodding someone into action, but that doesn't always work. One thing, Sean, while you are doing all of this (and thanks for that!) is to be thinking about ways to possibly change the workflow for issues (and this goes for anyone else using the new tracker). At some point we should have a discussion about how we want to change how things are handled so that we are happy with it and not trying to match how SF did things. -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] Other SSL issues in the tracker have been marked
> The problematic test is this one:
>
> File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py",
> line 77, in testSSLconnect
> s.connect(("pop.gmail.com", 995))
> File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\ssl.py", line 170,
> in connect
> if self._sslobj or (self.getsockname()[1] != 0):
> File "", line 1, in getsockname
> error: (10022, 'Invalid argument')
Actually, I think this is a bug in the Windows implementation of the
socket interface. The question is, what should s.getsockname() return
(or throw) if called on an unbound socket instance? Unix decided one
way, and Windows another (and not a particularly good way). I'll post
an issue to the tracker.
Bill
___
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] Triage of old tracker bugs: Any use?
Sean> I kind of figure that something that's in "high" priority, that Sean> has been sitting there for 46 months, either needs to have some Sean> activity on it or should be pushed to a lower priority. Note that it might have been high priority for the submitter. That doesn't necessarily mean it should have been marked that way though. Sean> Is doing this sort of triage or administration work useful? Any Sean> recommendations on what you'd like to have happen in this sort of Sean> task? I think it should be useful. If nothing else, you might add a comment asking the submitter if this is still a problem. If something's been there for nearly four years it's possible that it was solved in a later release or worked around by other means. Skip ___ 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] Other SSL issues in the tracker have been marked
On 8/28/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > The problematic test is this one:
> >
> > File
> > "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py", line
> > 77, in testSSLconnect
> > s.connect(("pop.gmail.com", 995))
> > File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\ssl.py", line
> > 170, in connect
> > if self._sslobj or (self.getsockname()[1] != 0):
> > File "", line 1, in getsockname
> > error: (10022, 'Invalid argument')
>
> Actually, I think this is a bug in the Windows implementation of the
> socket interface. The question is, what should s.getsockname() return
> (or throw) if called on an unbound socket instance? Unix decided one
> way, and Windows another (and not a particularly good way). I'll post
> an issue to the tracker.
Well, that's just what you get with two independent implementations of
a spec. We don't try to hide the differences between the sockets stack
in Unix and Windows -- you'll just have to work around it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Other SSL issues in the tracker have been marked
> Well, that's just what you get with two independent implementations of > a spec. We don't try to hide the differences between the sockets stack > in Unix and Windows -- you'll just have to work around it. No problem. But I think it's still a bug -- the "spec" (where is it?) should say what we want. I'll file an issue on it. Bill ___ 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] test_calendar broken on trunk
[EMAIL PROTECTED] wrote: > On the community trunk buildbots this checkin: > >1. > > Changed by: walter.doerwald > Changed at: Tue 28 Aug 2007 16:38:27 > Branch: trunk > Revision: 57620 > > Changed files: > * trunk/Doc/library/calendar.rst > * trunk/Lib/calendar.py > Comments: > > Fix title endtag in HTMLCalender.formatyearpage(). Fix documentation > for > HTMLCalender.formatyearpage() (there's no themonth parameter). > > This fixes issue1046. > > broke test_calendar. Details here: > > http://www.python.org/dev/buildbot/community/all/ Should be fixed in r57628. Servus, Walter ___ 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] Other SSL issues in the tracker have been marked
So, the patch is attached to issue 1052. I sent it out to python-dev, but it got blocked (too big). http://bugs.python.org/file8352/ssl-patch-5 This contains a number of things: 1) Improve the documentation of the SSL module, with a fuller explanation of certificate usage, another reference, proper formatting of this and that. 2) Fix Windows bug in ssl.py, and general bug in sslsocket.close(). Remove some unused code from ssl.py. Allow accept() to be called on sslsocket sockets. 3) Use try-except-else in import of ssl in socket.py. Deprecate use of socket.ssl(). 4) Remove use of socket.ssl() in every library module, except for test_socket_ssl.py and test_ssl.py. Bill ___ 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] Other SSL issues in the tracker have been marked
Hi Bill, I think it's time you get to do your own checkins. There's a protocol but I forget how to do it -- I think you mail your ssh key to Martin. --Guido On 8/28/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > So, the patch is attached to issue 1052. I sent it out to python-dev, > but it got blocked (too big). > > http://bugs.python.org/file8352/ssl-patch-5 > > This contains a number of things: > > 1) Improve the documentation of the SSL module, with a fuller >explanation of certificate usage, another reference, proper >formatting of this and that. > > 2) Fix Windows bug in ssl.py, and general bug in sslsocket.close(). >Remove some unused code from ssl.py. Allow accept() to be called on >sslsocket sockets. > > 3) Use try-except-else in import of ssl in socket.py. Deprecate use of >socket.ssl(). > > 4) Remove use of socket.ssl() in every library module, except for >test_socket_ssl.py and test_ssl.py. > > Bill > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Avoiding cascading test failures
On 8/22/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> When I was fixing tests failing in the py3k branch, I found the number
> duplicate failures annoying. Often, a single bug, in an important
> method or function, caused a large number of testcase to fail. So, I
> thought of a simple mechanism for avoiding such cascading failures.
>
> My solution is to add a notion of dependency to testcases. A typical
> usage would look like this:
>
> @depends('test_getvalue')
> def test_writelines(self):
> ...
> memio.writelines([buf] * 100)
> self.assertEqual(memio.getvalue(), buf * 100)
> ...
This definitely seems like a neat idea. Some thoughts:
* How do you deal with dependencies that cross test modules? Say test
A depends on test B, how do we know whether it's worthwhile to run A
if B hasn't been run yet? It looks like you run the test anyway (I
haven't studied the code closely), but that doesn't seem ideal.
* This might be implemented in the wrong place. For example, the [x
for x in dir(self) if x.startswith('test')] you do is most certainly
better-placed in a custom TestLoader implementation. That might also
make it possible to order tests based on their dependency graph, which
could be a step toward addressing the above point.
But despite that, I think it's a cool idea and worth pursuing. Could
you set up a branch (probably of py3k) so we can see how this plays
out in the large?
Collin Winter
___
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] Other SSL issues in the tracker have been marked
Bill, Please mail your ssh key as an attachment to [EMAIL PROTECTED] n -- On 8/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Hi Bill, > > I think it's time you get to do your own checkins. There's a protocol > but I forget how to do it -- I think you mail your ssh key to Martin. > > --Guido > > On 8/28/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > So, the patch is attached to issue 1052. I sent it out to python-dev, > > but it got blocked (too big). > > > > http://bugs.python.org/file8352/ssl-patch-5 > > > > This contains a number of things: > > > > 1) Improve the documentation of the SSL module, with a fuller > >explanation of certificate usage, another reference, proper > >formatting of this and that. > > > > 2) Fix Windows bug in ssl.py, and general bug in sslsocket.close(). > >Remove some unused code from ssl.py. Allow accept() to be called on > >sslsocket sockets. > > > > 3) Use try-except-else in import of ssl in socket.py. Deprecate use of > >socket.ssl(). > > > > 4) Remove use of socket.ssl() in every library module, except for > >test_socket_ssl.py and test_ssl.py. > > > > Bill > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ 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] Triage of old tracker bugs: Any use?
> Is doing this sort of triage or administration work useful? Any > recommendations on what you'd like to have happen in this sort of task? Down-grading things that were once high-priority is certainly reasonable. Of the very old bugs, it would be useful to find out whether they are still reproducable, and, if there is no straight-forward way to reproduce them, ask the submitter to provide a test case (if there is a test case that now passes in a case where it apparently did not pass back then, close it as works-for-me). It would also be good to triage all reports that have not seen any feedback. Unfortunately, it's not easy currently to query the tracker for these, so perhaps the "chatting" state needs to be brought back first. 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
