Re: [Python-Dev] hg verify warnings
Hi Tim, On Tue, Aug 20, 2013 at 1:48 AM, Tim Peters wrote: >>> warning: copy source of 'Modules/_threadmodule.c' not in parents of >>> 60ad83716733 >>> warning: copy source of 'Objects/bytesobject.c' not in parents of >>> 64bb1d258322 >>> warning: copy source of 'Objects/stringobject.c' not in parents of >>> 357e268e7c5f I've seen this once already (with another big repository). The problem I had was only these warnings when running "hg verify", and it was fixed by simply checking out a new copy of the repository. It seems that you have the same problem: for example my own copy of CPython doesn't show any warning in "hg verify". I've deleted my slightly-broken repo by then (as it was already several years old I suspected an old version of mercurial). Maybe I shouldn't have. How about you send your repository to the Mercurial bug tracker? A bientôt, Armin. ___ 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] Status of 3.2 in Hg repository?
Hi Tim, Le Mon, 19 Aug 2013 23:25:58 -0500, Tim Peters a écrit : > > hg log -r 3.2 > changeset: 83826:b9b521efeba3 > branch: 3.2 > parent: 83739:6255b40c6a61 > user:Antoine Pitrou > date:Sat May 18 17:56:42 2013 +0200 > summary: Issue #17980: Fix possible abuse of ssl.match_hostname() > for denial of service using certificates with many wildcards > (CVE-2013-2099). Oops, that's me :-S Now I don't remember if I omitted to merge deliberately, or if that was an oversight. For the record, the issue was fixed in 3.3 too, albeit not with a merge changeset. Regards Antoine. ___ 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] hg verify warnings
[Tim] warning: copy source of 'Modules/_threadmodule.c' not in parents of 60ad83716733 warning: copy source of 'Objects/bytesobject.c' not in parents of 64bb1d258322 warning: copy source of 'Objects/stringobject.c' not in parents of 357e268e7c5f [Armin] > I've seen this once already (with another big repository). The > problem I had was only these warnings when running "hg verify", and it > was fixed by simply checking out a new copy of the repository. It > seems that you have the same problem: for example my own copy of > CPython doesn't show any warning in "hg verify". Try running "hg verify -v" - these warnings only appear when verify is run in verbose mode. > I've deleted my slightly-broken repo by then (as it was already > several years old I suspected an old version of mercurial). Maybe I > shouldn't have. How about you send your repository to the Mercurial > bug tracker? Other people already have, for other projects. The developers don't care much; e.g., http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/23195 ___ 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] Status of 3.2 in Hg repository?
[Tim] >> > hg log -r 3.2 >> changeset: 83826:b9b521efeba3 >> branch: 3.2 >> parent: 83739:6255b40c6a61 >> user:Antoine Pitrou >> date:Sat May 18 17:56:42 2013 +0200 >> summary: Issue #17980: Fix possible abuse of ssl.match_hostname() >> for denial of service using certificates with many wildcards >> (CVE-2013-2099). [Antoine] > Oops, that's me :-S > Now I don't remember if I omitted to merge deliberately, or if that was > an oversight. Well, yours is just the tip of the 3.2 branch. 3.2 was already active when you made this commit, left over from the 3.2.5 release fiddling (when, presumably, a merge to default was also skipped): > hg log -v -r "children(ancestor(3.2, default)):: and branch(3.2)" changeset: 83738:cef745775b65 branch: 3.2 tag: v3.2.5 user:Georg Brandl date:Sun May 12 12:28:20 2013 +0200 files: Include/patchlevel.h Lib/distutils/__init__.py Lib/idlelib/idlever.py Misc/NEWS Misc/RPM/python-3.2.spec README description: Bump to version 3.2.5. changeset: 83739:6255b40c6a61 branch: 3.2 user:Georg Brandl date:Sun May 12 12:28:30 2013 +0200 files: .hgtags description: Added tag v3.2.5 for changeset cef745775b65 changeset: 83826:b9b521efeba3 branch: 3.2 parent: 83739:6255b40c6a61 user:Antoine Pitrou date:Sat May 18 17:56:42 2013 +0200 files: Lib/ssl.py Lib/test/test_ssl.py Misc/NEWS description: Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service using certificates with many wi ldcards (CVE-2013-2099). > For the record, the issue was fixed in 3.3 too, albeit not with a merge > changeset. In that case, I bet this one is easy to fix, for someone who knows what they're doing ;-) ___ 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] Status of 3.2 in Hg repository?
On Tue, 20 Aug 2013 10:43:57 -0500, Tim Peters wrote: > [Tim] > >> > hg log -r 3.2 > >> changeset: 83826:b9b521efeba3 > >> branch: 3.2 > >> parent: 83739:6255b40c6a61 > >> user:Antoine Pitrou > >> date:Sat May 18 17:56:42 2013 +0200 > >> summary: Issue #17980: Fix possible abuse of ssl.match_hostname() > >> for denial of service using certificates with many wildcards > >> (CVE-2013-2099). > > [Antoine] > > Oops, that's me :-S > > Now I don't remember if I omitted to merge deliberately, or if that was > > an oversight. > > Well, yours is just the tip of the 3.2 branch. 3.2 was already active > when you made this commit, left over from the 3.2.5 release fiddling > (when, presumably, a merge to default was also skipped): Georg indicated at the time that not merging was intentional. --David ___ 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] Status of 3.2 in Hg repository?
On Tue, 20 Aug 2013 13:16:05 -0400 "R. David Murray" wrote: > On Tue, 20 Aug 2013 10:43:57 -0500, Tim Peters wrote: > > [Tim] > > >> > hg log -r 3.2 > > >> changeset: 83826:b9b521efeba3 > > >> branch: 3.2 > > >> parent: 83739:6255b40c6a61 > > >> user:Antoine Pitrou > > >> date:Sat May 18 17:56:42 2013 +0200 > > >> summary: Issue #17980: Fix possible abuse of ssl.match_hostname() > > >> for denial of service using certificates with many wildcards > > >> (CVE-2013-2099). > > > > [Antoine] > > > Oops, that's me :-S > > > Now I don't remember if I omitted to merge deliberately, or if that was > > > an oversight. > > > > Well, yours is just the tip of the 3.2 branch. 3.2 was already active > > when you made this commit, left over from the 3.2.5 release fiddling > > (when, presumably, a merge to default was also skipped): > > Georg indicated at the time that not merging was intentional. Ah, now I remember indeed: http://mail.python.org/pipermail/python-committers/2013-May/002580.html Thanks Antoine. ___ 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] Status of 3.2 in Hg repository?
[Tim] > > hg log -r 3.2 > changeset: 83826:b9b521efeba3 > branch: 3.2 > parent: 83739:6255b40c6a61 > user:Antoine Pitrou > date:Sat May 18 17:56:42 2013 +0200 > summary: Issue #17980: Fix possible abuse of ssl.match_hostname() > for denial of service using certificates with many wildcards > (CVE-2013-2099). [Antoine] Oops, that's me :-S Now I don't remember if I omitted to merge deliberately, or if that was an oversight. [Tim] >>> Well, yours is just the tip of the 3.2 branch. 3.2 was already active >>> when you made this commit, left over from the 3.2.5 release fiddling >>> (when, presumably, a merge to default was also skipped): [R. David Murray] >> Georg indicated at the time that not merging was intentional. [Antoine] > Ah, now I remember indeed: > http://mail.python.org/pipermail/python-committers/2013-May/002580.html Which says: I asked about this on IRC and was told that 3.2 is now a standalone branch like 2.7. Security fixes will be applied by the release manager only, and Georg doesn't see any point in null merging the commits. Isn't the point exactly the same as for all other "old-to-new branch" null merges? That is, 1. So that 3.2 doesn't show up as an active branch under "hg branches"; and, 2. So that security fixes applied to the 3.2 branch can be easily forward-ported to the 3.3 and default branches via no-hassle merges. What is gained by _not_ merging here? I don't see it. I suppose the answer, as to everything else, lies in "hg strip" . ___ 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] Status of 3.2 in Hg repository?
On Tue, 20 Aug 2013 12:47:46 -0500 Tim Peters wrote: > > [Antoine] > > Ah, now I remember indeed: > > http://mail.python.org/pipermail/python-committers/2013-May/002580.html > > Which says: > > I asked about this on IRC and was told that 3.2 is now a > standalone branch like 2.7. Security fixes will be applied > by the release manager only, and Georg doesn't see any > point in null merging the commits. > > Isn't the point exactly the same as for all other "old-to-new branch" > null merges? That is, > > 1. So that 3.2 doesn't show up as an active branch under "hg branches"; and, > > 2. So that security fixes applied to the 3.2 branch can be easily > forward-ported to the 3.3 and default branches via no-hassle merges. > > What is gained by _not_ merging here? I don't see it. Perhaps Georg doesn't like merges? ;-) I suppose what's gained is "one less command to type". Regards Antoine. ___ 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] PEP 446: issue with sockets
Hi, I have a new question for my PEP 446 (inheritance of file descriptors). os.get/set_inheritable(handle) has strange behaviour on Windows, and so I would like to add new os.get/set_handle_inheritable() functions to avoid it. The problem is that a socket would require a different function depending on the OS: os.get/set_handle_inheritable() on Windows, os.get/set_inheritable() on UNIX. Should I add a portable helper to the socket module (socket.get/set_inheritable)? Or add 2 methods to the socket class? Now the details. I have an issue with sockets and the PEP 446. On Windows, my implementation of the os.set_inheritable(fd: int, inheritable: bool) function tries to guess if fd is a file descriptor or a handle. The reason is that the fileno() method of a socket returns a file descriptor on UNIX, whereas it returns a handle on Windows. It is convinient to have a os.set_interiable() function which accepts both types. The issue is that os.get_inheritable() does the same guess and it has a strange behaviour. Calling os.get_inheritable() with integers in the range(20) has a border effect: open(filename) creates a file descriptor 10, whereas it creates a file descriptor 3 if get_inheritable() was not called (why 10 and not 3?). To avoid the border effect, it's better to not guess if the parameter is a file descriptor or a Windows handle, and a new two new functions: os.get_handle_inheritable() and os.set_handle_inheritable(). Victor ___ 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] PEP 446: issue with sockets
2013/8/21 Victor Stinner : > Should I add a portable helper to the > socket module (socket.get/set_inheritable)? Add the two following functions to the socket module: def get_inheritable(sock): if os.name == 'nt': return os.get_handle_inheritable(sock.fileno()) else: return os.get_inheritable(sock.fileno()) def set_inheritable(sock, inheritable): if os.name == 'nt': os.set_handle_inheritable(sock.fileno(), inheritable) else: os.set_inheritable(sock.fileno(), inheritable) Usage: socket.get_inheritable(sock) and socket.set_inheritable(sock, True) > Or add 2 methods to the socket class? Add the two following methods to the socket class: def get_inheritable(self): if os.name == 'nt': return os.get_handle_inheritable(self.fileno()) else: return os.get_inheritable(self.fileno()) def set_inheritable(self, inheritable): if os.name == 'nt': os.set_handle_inheritable(self.fileno(), inheritable) else: os.set_inheritable(self.fileno(), inheritable) Usage: s.get_inheritable() and sock.set_inheritable(True) Victor ___ 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] PEP 446: issue with sockets
Agreed that guessing whether something's a handle or not is terrible. If this is truly only for sockets then maybe it should live in the socket module? Also, are you sure the things returned by socket.fleno() are really Windows handles? I thought they were some other artificial namespace used just by sockets. On Tue, Aug 20, 2013 at 4:30 PM, Victor Stinner wrote: > Hi, > > I have a new question for my PEP 446 (inheritance of file descriptors). > > os.get/set_inheritable(handle) has strange behaviour on Windows, and > so I would like to add new os.get/set_handle_inheritable() functions > to avoid it. The problem is that a socket would require a different > function depending on the OS: os.get/set_handle_inheritable() on > Windows, os.get/set_inheritable() on UNIX. Should I add a portable > helper to the socket module (socket.get/set_inheritable)? Or add 2 > methods to the socket class? > > Now the details. > > I have an issue with sockets and the PEP 446. On Windows, my > implementation of the os.set_inheritable(fd: int, inheritable: bool) > function tries to guess if fd is a file descriptor or a handle. The > reason is that the fileno() method of a socket returns a file > descriptor on UNIX, whereas it returns a handle on Windows. It is > convinient to have a os.set_interiable() function which accepts both > types. > > The issue is that os.get_inheritable() does the same guess and it has > a strange behaviour. Calling os.get_inheritable() with integers in the > range(20) has a border effect: open(filename) creates a file > descriptor 10, whereas it creates a file descriptor 3 if > get_inheritable() was not called (why 10 and not 3?). > > To avoid the border effect, it's better to not guess if the parameter > is a file descriptor or a Windows handle, and a new two new functions: > os.get_handle_inheritable() and os.set_handle_inheritable(). > > Victor > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (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] PEP 446: issue with sockets
Since this is a new API and only applies to sockets, making them methods sounds good. (I'd put the 'nt' test outside the method defs though so they are tested only once per import.) On Tue, Aug 20, 2013 at 4:57 PM, Victor Stinner wrote: > 2013/8/21 Victor Stinner : > > Should I add a portable helper to the > > socket module (socket.get/set_inheritable)? > > Add the two following functions to the socket module: > > def get_inheritable(sock): > if os.name == 'nt': > return os.get_handle_inheritable(sock.fileno()) > else: > return os.get_inheritable(sock.fileno()) > > def set_inheritable(sock, inheritable): > if os.name == 'nt': > os.set_handle_inheritable(sock.fileno(), inheritable) > else: > os.set_inheritable(sock.fileno(), inheritable) > > Usage: socket.get_inheritable(sock) and socket.set_inheritable(sock, True) > > > Or add 2 methods to the socket class? > > Add the two following methods to the socket class: > > def get_inheritable(self): > if os.name == 'nt': > return os.get_handle_inheritable(self.fileno()) > else: > return os.get_inheritable(self.fileno()) > > def set_inheritable(self, inheritable): > if os.name == 'nt': > os.set_handle_inheritable(self.fileno(), inheritable) > else: > os.set_inheritable(self.fileno(), inheritable) > > Usage: s.get_inheritable() and sock.set_inheritable(True) > > Victor > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (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] PEP 446: issue with sockets
2013/8/21 Guido van Rossum : > Also, are you sure the things returned by socket.fleno() are really Windows > handles? I thought they were some other artificial namespace used just by > sockets. (You know what? I know understand and love the UNIX concept "everything is file"!) I don't know if a socket handle is similar to file handles or if they are specials. At least, GetHandleInformation() and SetHandleInformation() functions, used by os.get/set_handle_inheritable(), accept socket handles. Outside the socket module, the subprocess and multiprocessing modules use also Windows handles. The subprocess has for example a private _make_inheritable() method which could be replaced with os.set_handle_inheritable(). I'm not sure because _make_inheritable() duplicates the input handle, whereas os.set_handle_inheritable() modify directly the handle. I don't know why the handle needs to be duplicated. Victor ___ 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] Status of 3.2 in Hg repository?
[Tim, wondering why the 3.2 branch isn't "inactive"] >> ... >> What is gained by _not_ merging here? I don't see it. [Antoine Pitrou] > Perhaps Georg doesn't like merges? ;-) > I suppose what's gained is "one less command to type". So let's try a different question ;-) Would anyone _object_ to completing the process described in the docs: merge 3.2 into 3.3, then merge 3.3 into default? I'd be happy to do that. I'd throw away all the merge changes except for adding the v3,2.5 tag to .hgtags. The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-) ___ 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] Status of 3.2 in Hg repository?
On Aug 20, 2013, at 07:33 PM, Tim Peters wrote: >So let's try a different question ;-) Would anyone _object_ to >completing the process described in the docs: merge 3.2 into 3.3, >then merge 3.3 into default? I'd be happy to do that. I'd throw away >all the merge changes except for adding the v3,2.5 tag to .hgtags. > >The only active branches remaining would be `default` and 2.7, which >is what I expected when I started this ;-) That's what I'd expect to, so no objections from me. But I'm only the lowly 2.6 RM and I will soon be rid of that particular albatross! FWIW, I'm still merging relevant 2.6 changes into 2.7 (or null merging them if not relevant). Oh, and welcome back Uncle Timmy! (If that's you're real name.) -Barry ___ 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] PEP 446: issue with sockets
2013/8/21 Guido van Rossum : > Since this is a new API and only applies to sockets, making them methods > sounds good. (I'd put the 'nt' test outside the method defs though so they > are tested only once per import.) I added get_inheritable() and set_inheritable() methods to socket.socket. The names are PEP 8 compliant, whereas socket.socket.getblocking() and socket.socket.settimeout() are not :-) So we have 4 new functions and 2 new methods just to get and set the inheritable attribute :-) http://www.python.org/dev/peps/pep-0446/#new-functions-and-methods We might remove os.get/set_handle_inheritable() from the PEP 446, if they are not really useful. Victor ___ 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] format, int, and IntEnum
On 08/14/2013 09:27 PM, Nick Coghlan wrote:
For enums, I believe they should be formatted like their
base types (so !s and !r will show the enum name, anything without
coercion will show the value) .
I agree. While one of the big reasons for an Enum type was the pretty
str and repr, I don't see format in that area.
How often will one type in `"{}".format(some_var)` to find out what type
of object one has? Myself, I would just type `some_var`.
--
~Ethan~
___
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
