[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Zbyszek Szmek zbys...@in.waw.pl added the comment: What system and version are you running? Linux (debian amd64), Python is compiled from hg (1ea8b7233fd7). The error directly comes from textwrap. In the other hand, textwrap.wrap works with widths down to 1 (on 3.2.2), which suggests that argparse is calling it wrong. Except that it is not on my system. That's really surprising, because it is all pure Python code and don't really see how it _could_ be right: take $COLUMNS, subtract, subtract, and sooner or later _width will go below 0. Could you add 'print(width)' before the call to textwrap return _textwrap.wrap(text, width) to see if -1 is being passed? Prints -1. The code works fine on 3.2.2, Win7, IDLE, narrowest window possible (about 14 chars), which actually wraps to the window width. Oh, I just tried it in IDLE and it prints: 64 64 64 64 usage: ... in a very small window (30 cells wide). So IDLE is just doesn't allow you to go below a certain size. See also #13107. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Terry J. Reedy tjre...@udel.edu added the comment: I am not setting columns, so that might be the important difference. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Zbyszek Szmek zbys...@in.waw.pl added the comment: I am not setting columns, so that might be the important difference. Yeah, the whole example with IDLE is moot: argparse only checks $COLUMNS and defaults to 80, so if COLUMNS is not set, you are only checking if the code works with 80 columns. Please try my commandline example or set os.environ['COLUMNS'] = 15. I get the exception in IDLE too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13511] Specifying multiple lib and include directories on linux
Ronald Oussoren ronaldousso...@mac.com added the comment:
He's probably referring to this fragment in setup.py:
if platform == 'darwin':
# This should work on any unixy platform ;-)
# If the user has bothered specifying additional -I and -L flags
# in OPT and LDFLAGS we might as well use them here.
# NOTE: using shlex.split would technically be more correct, but
# also gives a bootstrap problem. Let's hope nobody uses directories
# with whitespace in the name to store libraries.
cflags, ldflags = sysconfig.get_config_vars(
'CFLAGS', 'LDFLAGS')
for item in cflags.split():
if item.startswith('-I'):
inc_dirs.append(item[2:])
for item in ldflags.split():
if item.startswith('-L'):
lib_dirs.append(item[2:])
The entire block was added when I worked on the Mac port with Jack Jansen. It
ensures that additional include and lib directories specified through the 'OPT'
and 'LDFLAGS' shell variables get added to the search path used by distutils.
As the comment says this should be safe all unity platforms, not just OSX.
IIRC the platform test is there because we couldn't easily test on other
platforms and didn't want to accidentally break stuff (this was before we had a
good buildbot setup).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13511
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13724] socket.create_connection and multiple IP addresses
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Terry J. Reedy tjre...@udel.edu added the comment: Now I get error, even with Window actually about 100 columns wide. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13725] regrtest does not recognize -d flag
New submission from Erno Tukia erno.tu...@iki.fi: ./python -m test --help -d/--debug -- print traceback for failed tests ./python -m test -d test_imaplib option -d not recognized Use --help for usage Patch included. -- components: Tests files: regrtest-debug.patch keywords: patch messages: 150790 nosy: etukia priority: normal severity: normal status: open title: regrtest does not recognize -d flag type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file24159/regrtest-debug.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13033] Add shutil.chowntree
Nick Coghlan ncogh...@gmail.com added the comment: I believe the current check_chown could be passed by a no-op (since the file will be owned by the current user even *before* the call to chowntree). Testing this properly is actually rather difficult (since the only uid and gid we can rely on are those of the current process). More significantly, I don't agree with the proposed error handling (i.e. attempting to roll back to the original state). Instead, I think it would be more appropriate to follow the rmtree ignore_errors/onerror style so that uses can either unconditionally ignore errors (including dir listing errors) or else tailor the error handling themselves. Any custom error handling should also cover the actual chown operation, not just directory listing errors inside os.walk. I think, like walkdir itself, there's enough under the hood here that the idea requires some baking time outside the standard library. How do you feel about migrating this discussion over to the walkdir issue tracker as a higher level API proposal there? (https://bitbucket.org/ncoghlan/walkdir/issues). I had a couple of other minor comments, although they're largely irrelevant given the more significant comments above: There's a gratuitous inconsistency in the type-checking for uid/gid (one uses isinstance(uid, str), the other not isinstance(gid, int). Neither is a particular good check for the None, integer or string case anyway. It would be better to just try the following in order: - is None - operator.index - _get_uid/gid (as appropriate) The dict initialisation and error handler definition may as well move inside the if statement. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13033 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13726] regrtest ambiguous -S flag
New submission from Erno Tukia erno.tu...@iki.fi:
./python -m test --help
-S/--slow -- print the slowest 10 tests
-S is used to continue running tests after an aborted run. It will
maintain the order a standard run (ie, this assumes -r is not used).
This is useful after the tests have prematurely stopped for some external
reason and you want to start running from where you left off rather
than starting from the beginning.
in Lib/test/regrtest.py
opts, args = getopt.getopt(sys.argv[1:], '...S...',
[..., 'slow', ... , 'start=', ...])
for o, a in opts:
elif o in ('-S', '--start'):
start = a
elif o in ('-S', '--slow'):
print_slow = True
At the moment -S (no args) and --slow (no args) are the same, not what the
documentation says and not how the code executes (-S goes with --start). Help
says nothing about --start.
--slow or --start needs a new short opt, and corrected documentation.
--
assignee: docs@python
components: Documentation, Tests
messages: 150792
nosy: docs@python, etukia
priority: normal
severity: normal
status: open
title: regrtest ambiguous -S flag
type: behavior
versions: Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13726
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13716] distutils doc contains lots of XXX
Georg Brandl ge...@python.org added the comment: I would make comments out of the XXX, and if a whole section is just that XXX, remove the section as well. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Hynek Schlawack h...@ox.cx added the comment: What's the current state here? Anyone working on a solution or are we waiting how http://hg.python.org/features/pathlib/ will work out? If the consensus is to add a generic walker method, wouldn't be appropriate to open a new bug and add it as dependency? Or is there one I've missed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Paul McMillan wrote: I'll upload a patch that demonstrates the collisions counting strategy to show that detecting the problem is easy. Whether just raising an exception is a good idea, is another issue. I'm in cautious agreement that collision counting is a better strategy. The dict implementation performance would suffer from randomization. The dict implementation could then alter the hash parameter and recreate the dict table in case the number of collisions exceeds a certain limit, thereby actively taking action instead of just relying on randomness solving the issue in most cases. This is clever. You basically neuter the attack as you notice it but everything else is business as usual. I'm concerned that this may end up being costly in some edge cases (e.g. look up how many collisions it takes to force the recreation, and then aim for just that many collisions many times). Unfortunately, each dict object has to discover for itself that it's full of offending hashes. Another approach would be to neuter the offending object by changing its hash, but this would require either returning multiple values, or fixing up existing dictionaries, neither of which seems feasible. I ran some experiments with the collision counting patch and could not trigger it in normal applications, not even in cases that are documented in the dict implementation to have a poor collision resolution behavior (integers with zeros the the low bits). The probability of having to deal with dictionaries that create over a thousand collisions for one of the key objects in a real life application appears to be very very low. Still, it may cause problems with existing applications for the Python dot releases, so it's probably safer to add it in a disabled-per-default form there (using an environment variable to adjust the setting). For 3.3 it could be enabled per default and it would also make sense to allow customizing the limit using a sys module setting. The idea with adding a parameter to the hash method/slot in order to have objects provide a hash family function instead of a fixed unparametrized hash function would probably have to be implemented as additional hash method, e.g. .__uhash__() and tp_uhash (u for universal). The builtin types should then grow such methods in order to make hashing safe against such attacks. For objects defined in 3rd party extensions, we would need to encourage implementing the slot/method as well. If it's not implemented, the dict implementation would have to fallback to raising an exception. Please note that I'm just sketching things here. I don't have time to work on a full-blown patch, just wanted to show what I meant with the collision counting idea and demonstrate that it actually works as intended. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13727] Accessor macros for PyDateTime_Delta members
New submission from Amaury Forgeot d'Arc amaur...@gmail.com: All objects of the datetime module have macros to access their properties, except timedelta. This simple patch adds the macros PyDateTime_DELTA_GET_DAYS, PyDateTime_DELTA_GET_SECONDS, PyDateTime_DELTA_GET_MICROSECONDS; module developers are encouraged to use these instead of obj-seconds for example. Motivation: PyPy cannot easily expose PyDateTime_Delta fields because datetime is implemented as a pure Python module and it's difficult to rebuild a C structure from a heap type. In PyPy these macros are actually functions, which do something similar to PyLong_AsLong(PyObject_GetAttrString(obj, seconds)): https://bitbucket.org/pypy/pypy/src/b67e65d709e1/pypy/module/cpyext/cdatetime.py#cl-235 -- files: timedelta_macros.patch keywords: patch messages: 150796 nosy: amaury.forgeotdarc priority: normal severity: normal stage: patch review status: open title: Accessor macros for PyDateTime_Delta members versions: Python 3.3 Added file: http://bugs.python.org/file24160/timedelta_macros.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13692] 2to3 mangles from . import frobnitz
Éric Araujo mer...@netwok.org added the comment: Thanks for the report, but 3.1 does not get bug fixes any more. Maybe Benjamin would like to add a regression test for this, so I’m leaving the decision to close this report to him. -- nosy: +benjamin.peterson, eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13692 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13716] distutils doc contains lots of XXX
Éric Araujo mer...@netwok.org added the comment: These are the XXX: XXX true? does ANSI say anything about this? XXX defaults to what? XXX see also. XXX see also. XXX see also. XXX see also. XXX see also. The first two are questions that can be answered, and when I research them for the packaging docs I could also backport the changes to the distutils docs; what to do for the other instances is less clear, so just deleting may be better than turning them into comments that will never get solved. -- assignee: docs@python - eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13691] pydoc help (or help('help')) claims to run a help utility; does nothing
Éric Araujo mer...@netwok.org added the comment: I’m interested in this, so I’m taking assignment. If a contributor is interested in making a patch I’ll review it, otherwise I’ll say when I start on a patch. -- assignee: - eric.araujo keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13691 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13716] distutils doc contains lots of XXX
Georg Brandl ge...@python.org added the comment: Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13716] distutils doc contains lots of XXX
Florent Xicluna florent.xicl...@gmail.com added the comment: The proposed solution is ok. It sounds like unfinished documentation when you hit an XXX. For the /dev/ documentation, it's OK, but for the released version, we should avoid it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13728] Description of -m and -c cli options wrong?
New submission from Sandro Tosi sandro.t...@gmail.com: Hi, looking at http://mail.python.org/pipermail/docs/2011-December/006672.html I tried to replicate what the user said, and *it seems* that -c and -m doesn't add the current directory to the start of sys.path: $ echo -e import sys\nprint (sys.path) dummy.py ; ./python -mdummy ['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', '/home/morph/cpython/py27/Lib/plat-linux2', '/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', '/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', '/usr/local/lib/python2.7/site-packages'] and $ ./python -c import dummy ['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', '/home/morph/cpython/py27/Lib/plat-linux2', '/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', '/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', '/usr/local/lib/python2.7/site-packages'] the same sys.path as from the interactive shell: $ ./python Python 2.7.2+ (2.7:f0666e56a552, Jan 7 2012, 16:31:06) [GCC 4.6.1] on linux2 Type help, copyright, credits or license for more information. import sys [38650 refs] sys.path ['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', '/home/morph/cpython/py27/Lib/plat-linux2', '/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', '/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', '/usr/local/lib/python2.7/site-packages'] [38657 refs] So, is http://docs.python.org/using/cmdline.html#interface-options correct in saying he current directory will be added to the start of sys.path (allowing modules in that directory to be imported as top level modules).? (and so forth for -m option?) am I confused? -- assignee: docs@python components: Documentation messages: 150802 nosy: docs@python, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: Description of -m and -c cli options wrong? versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13728 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12989] Consistently handle path separator in Py_GetPath on Windows
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13692] 2to3 mangles from . import frobnitz
Changes by Benjamin Peterson benja...@python.org: -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13692 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13550] Rewrite logging hack of the threading module
Charles-François Natali neolo...@free.fr added the comment: Alright, Nick agreed on python-dev to remove the logging hack. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13550 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13729] Evaluation order for dics key/value
New submission from Sandro Tosi sandro.t...@gmail.com:
Hello, following up
http://mail.python.org/pipermail/docs/2011-December/006782.html , I'm opening
this issue to have others confirmation of what's happening:
echo -e def ev(r):\nprint(r)\nreturn r\n\n{ev(1): ev(2), ev(3):
ev(4)} | ./python
2
1
4
3
(this applies for 2.7/3.2/default) so it seems the value expressions are
evaluated before the key expressions, so the
{expr1: expr2, expr3: expr4}
in http://docs.python.org/reference/expressions.html#evaluation-order has to be
updated in
{expr2: expr1, expr4: expr3}
Is that correct/can someone confirm this is the expected behavior?
--
assignee: docs@python
components: Documentation
messages: 150804
nosy: docs@python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Evaluation order for dics key/value
versions: Python 2.7, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13729
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13550] Rewrite logging hack of the threading module
Éric Araujo mer...@netwok.org added the comment: haypo’s threading_note_global looks good to me. The only thing I’m not sure about is the signature change from X(verbose, *args, **kwargs) to X(*args, **kwargs): is it okay? (BTW you probably want to delete the obsolete reference to ihooks in a comment before committing.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13550 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Aaron Maenpaa aa...@maenpaa.ca added the comment: This patch fixes the rzinfo typo as well as the GMT2 issue (GMT +2 should behave exactly the same as GMT +1 with regards to DST, it's base offset should simply be +2 hours instead of +1). This does not; however, address the comment about the first line of the tzinfo.utcoffset(). The fact that tzinfo.utcoffset() should return a timedelta or None is addressed later in the same paragraph, as such I'm not sure the proposed change is an improvement. -- keywords: +patch nosy: +zacherates Added file: http://bugs.python.org/file24161/issue13666.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Aaron Maenpaa aa...@maenpaa.ca added the comment: Looks like the issue of the first line of utcoffsect was also raised in issue 8810. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Stephen Kelly steve...@gmail.com added the comment: Patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset eb39d862a250 by Charles-François Natali in branch '3.2': Issue #13502: threading: Fix a race condition in Event.wait() that made it http://hg.python.org/cpython/rev/eb39d862a250 New changeset 0fe63bb20e74 by Charles-François Natali in branch 'default': Issue #13502: threading: Fix a race condition in Event.wait() that made it http://hg.python.org/cpython/rev/0fe63bb20e74 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Antoine Pitrou pit...@free.fr added the comment: What's the current state here? Anyone working on a solution or are we waiting how http://hg.python.org/features/pathlib/ will work out? Well, I am not working on that one, so waiting for it to work out might be optimistic :) I don't know what to do with it (the pathlib): is such a feature desireable enough? If the consensus is to add a generic walker method, wouldn't be appropriate to open a new bug and add it as dependency? Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12005] modulo result of Decimal differs from float/int
Aaron Maenpaa aa...@maenpaa.ca added the comment: Here is a patch that adds an explination for the difference in the behaviour to the FAQ section of the Decimal documentation. -- keywords: +patch nosy: +zacherates Added file: http://bugs.python.org/file24162/issue12005.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8184] multiprocessing.managers will not fail if listening ocket already in use
Charles-François Natali neolo...@free.fr added the comment: I noticed that if bind() fails (in this case with EADDRINUSE), the socket isn't closed (FD leak). Here's a patch. -- keywords: +patch Added file: http://bugs.python.org/file24163/connection_error.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8184 ___diff --git a/Lib/multiprocessing/connection.py b/Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py +++ b/Lib/multiprocessing/connection.py @@ -575,10 +575,14 @@ ''' def __init__(self, address, family, backlog=1): self._socket = socket.socket(getattr(socket, family)) -self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) -self._socket.bind(address) -self._socket.listen(backlog) -self._address = self._socket.getsockname() +try: +self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) +self._socket.bind(address) +self._socket.listen(backlog) +self._address = self._socket.getsockname() +except OSError: +self._socket.close() +raise self._family = family self._last_accepted = None ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13730] Grammar mistake in Decimal documentation
New submission from Aaron Maenpaa aa...@maenpaa.ca: In the sentance: In contrast, numbers like 1.1 and 2.2 do not have an exact representations in binary floating point. there is a mismatch in number between an and representations. I suggest removing an to make the whole thing plural. A patch is attached. -- assignee: docs@python components: Documentation files: plural.diff keywords: patch messages: 150813 nosy: docs@python, zacherates priority: normal severity: normal status: open title: Grammar mistake in Decimal documentation versions: Python 3.3 Added file: http://bugs.python.org/file24164/plural.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13730 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
New submission from Aaron Maenpaa aa...@maenpaa.ca: The paragraph: The exactness carries over into arithmetic. In decimal floating point, 0.1 + 0.1 + 0.1 - 0.3 is exactly equal to zero. In binary floating point, the result is 5.5511151231257827e-017. While near to zero, the differences prevent reliable equality testing and differences can accumulate. For this reason, decimal is preferred in accounting applications which have strict equality invariants. ... has some awkward phrasing to my ear. I've attached a patch with a proposed alternative. -- assignee: docs@python components: Documentation files: rephrase.diff keywords: patch messages: 150814 nosy: docs@python, zacherates priority: normal severity: normal status: open title: Awkward phrasing in Decimal documentation versions: Python 3.3 Added file: http://bugs.python.org/file24165/rephrase.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13502] Documentation for Event.wait return value is either wrong or incomplete
Changes by Charles-François Natali neolo...@free.fr: -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Benjamin West bew...@gmail.com added the comment: Thanks Eric. I was thrown by this document: http://wiki.python.org/moin/Git which describes fetching the sources from SVN using git. I'm comfortable doing either, but it doesn't resolve my confusion. The version of argparse in the python checkout is 1.1: http://hg.python.org/cpython/file/default/Lib/argparse.py 64 __version__ = '1.1' but differs from the SVN version. whereas the argparse version available via google code is 1.2. The diffs indicate several changes not related to the change I'm attempting to make, which prevent my patch from applying cleanly. Looks like the HG version includes the 1.2 code... but I'm not sure why it would differ from SVN's trunk. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Benjamin West bew...@gmail.com added the comment: Thanks Eric. I was thrown by this document: http://wiki.python.org/moin/Git which describes fetching the sources from SVN using git. I'm comfortable doing either, but it doesn't resolve my confusion. The version of argparse in the python checkout is 1.1: http://hg.python.org/cpython/file/default/Lib/argparse.py 64 __version__ = '1.1' but differs from the SVN version. whereas the argparse version available via google code is 1.2. The diffs indicate several changes not related to the change I'm attempting to make, which prevent my patch from applying cleanly. Looks like the HG version includes the 1.2 code... but I'm not sure why it would differ from SVN's trunk. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13732] test_logging failure on Windows buildbots
New submission from Charles-François Natali neolo...@free.fr:
Commit 57295c4d81ac879dd2d804190b38b2e91f934acd broke Windows buildbots:
==
ERROR: test_rotator (test.test_logging.RotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 3543, in tearDown
os.unlink(fn)
PermissionError: [Error 32] The process cannot access the file because it is
being used by another process:
'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-9ozjk9.log'
==
FAIL: test_rotator (test.test_logging.RotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 3631, in test_rotator
self.assertEqual(data.decode(ascii), m1.msg + \n)
AssertionError: '1\r\n' != '1\n'
- 1
? -
+ 1
==
FAIL: test_should_not_rollover (test.test_logging.RotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 3536, in setUp
BaseTest.setUp(self)
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 114, in setUp
raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: [logging.StreamHandler object at
0x0EBAC540]
See
http://python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4180/steps/test/logs/stdio
and
http://python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5780/steps/test/logs/stdio
--
assignee: vinay.sajip
components: Tests
messages: 150817
nosy: neologix, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failure on Windows buildbots
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13732
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13587] Correcting the typos error in Doc/howto/urllib2.rst
Aaron Maenpaa aa...@maenpaa.ca added the comment: Here's a patch that makes the WWW-Authenticate headers in howto/urllib2 agree with rfc2617. -- keywords: +patch nosy: +zacherates Added file: http://bugs.python.org/file24166/issue13587.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
Raymond Hettinger raymond.hettin...@gmail.com added the comment: I'm sorry but I think the current wording is better that your proposed revision. When I get a chance, I'll revisit it to see if I can find another way to improve the text. -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Benjamin West bew...@gmail.com added the comment: Ok, here's a rough attempt at stubbing this out against a python checkout. Will try to look at adding tests. (BTW, subsequent GETs should not modify the bug tracker... this seems like a bug since GET should be idempotent, but SFTN from the double posting.) -- hgrepos: +101 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Benjamin West bew...@gmail.com added the comment: Ok, here's a rough attempt at stubbing this out against a python checkout. Will try to look at adding tests. (BTW, subsequent GETs should not modify the bug tracker... this seems like a bug since GET should be idempotent, but SFTN from the double posting.) -- hgrepos: +100 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13728] Description of -m and -c cli options wrong?
Eric Snow ericsnowcurren...@gmail.com added the comment: see http://docs.python.org/library/sys.html#sys.path As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first. So the empty string here is the current working directory (at the time the script is run?). -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13728 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
Aaron Maenpaa aa...@maenpaa.ca added the comment: That's fine. I'm not particularly attached to that phrasing. The one thing I would push for is to add a comma to ... decimal is preferred in accounting applications which have strict equality invariants. ... since, as far as I can tell, which have strict equality invariants is supposed to be a parenthetical statement explaining why accounting applications prefer to use decimal arithmetic, rather than a constraints on the preference for decimal arithmetic to only those accounting applications that have strict equality invariants. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13050] RLock support the context manager protocol but this is not documented
Aaron Maenpaa aa...@maenpaa.ca added the comment: Here is a patch that adds an note about using Locks, RLocks, Conditions, and Semaphores as context managers to each of their descriptions as well as a link to the Using locks, conditions, and semaphores in the with statement section. -- keywords: +patch nosy: +zacherates versions: +Python 3.3 Added file: http://bugs.python.org/file24167/issue13050.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
Raymond Hettinger raymond.hettin...@gmail.com added the comment: If you can't ascertain the meaning of the sentence, I'll consider making a change. Itherwise, this appears to have degenerated into trivial micro-wordsmithing and I'll close this as not being worth consuming any more of my time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
Aaron Maenpaa aa...@maenpaa.ca added the comment: I can understand what was meant. You're welcome to close the issue. Sorry for the nitpick. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13731] Awkward phrasing in Decimal documentation
Raymond Hettinger raymond.hettin...@gmail.com added the comment: No problem. Thanks for showing an interest in the quality of the documentation. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13050] RLock support the context manager protocol but this is not documented
Raymond Hettinger raymond.hettin...@gmail.com added the comment: This edit looks reasonable. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Tim Peters tim.pet...@gmail.com added the comment: [Marc-Andre] BTW: I wonder how long it's going to take before someone figures out that our merge sort based list.sort() is vulnerable as well... its worst- case performance is O(n log n), making attacks somewhat harder. I wouldn't worry about that, because nobody could stir up anguish about it by writing a paper ;-) 1. O(n log n) is enormously more forgiving than O(n**2). 2. An attacker need not be clever at all: O(n log n) is not only sort()'s worst case, it's also its _expected_ case when fed randomly ordered data. 3. It's provable that no comparison-based sorting algorithm can have better worst-case asymptotic behavior when fed randomly ordered data. So if anyone whines about this, tell 'em to go do something useful instead :-) -- nosy: +tim_one ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13732] test_logging failure on Windows buildbots
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 870f8fdfbada by Vinay Sajip in branch 'default': Closes #13732: now use os.linesep instead of a literal newline. http://hg.python.org/cpython/rev/870f8fdfbada -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2
New submission from Paul Smedley p...@smedley.id.au: Python 2.7.2 fails during compilation on OS/2 with: File ./setup.py, line 1154, in detect_modules for arg in sysconfig.get_config_var(CONFIG_ARGS).split()] AttributeError: 'NoneType' object has no attribute 'split' make: *** [sharedmods] Error 1 Attached diff for sysconfig.py corrects the problem -- components: Build files: sysconfig.py.diff keywords: patch messages: 150831 nosy: Paul.Smedley priority: normal severity: normal status: open title: Change required to sysconfig.py for Python 2.7.2 on OS/2 type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file24168/sysconfig.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin gzl...@googlemail.com added the comment: I built random-2.patch on my windows xp box (updating the project and fixing some compile errors in random.c required), and initialising crypto has a noticeable impact on startup time. The numbers vary a fair bit naturally, two representative runs are as follows: changeset 52796:1ea8b7233fd7 on default branch: timeit %PY3K% -c import sys;print(sys.version) 3.3.0a0 (default, Jan 7 2012, 00:12:45) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:0:16 am, Saturday, January 7 2012 Elapsed Time: 0:00:00.218 Process Time: 0:00:00.187 System Calls: 4193 Context Switches: 445 Page Faults: 1886 Bytes Read: 642542 Bytes Written:272 Bytes Other: 31896 with random-2.patch and fixes applied: timeit %PY3K% -c import sys;print(sys.version) 3.3.0a0 (default, Jan 7 2012, 00:58:32) [MSC v.1500 32 bit (Intel)] Version Number: Windows NT 5.1 (Build 2600) Exit Time:0:59 am, Saturday, January 7 2012 Elapsed Time: 0:00:00.296 Process Time: 0:00:00.234 System Calls: 4712 Context Switches: 642 Page Faults: 2049 Bytes Read: 1059381 Bytes Written:272 Bytes Other: 34544 This is with hot caches, cold will likely be worse, but a smaller percentage change. On a faster box, or with an SSD, or win 7, the delta will likely be smaller too. A 50-100ms slow down is consistent with the difference on Python 2.7 between calling `os.urandom(1)` or not. However, the baseline is faster with Python 2, frequently dipping under 100ms, so there this change could double the runtime of trivial scripts. -- nosy: +gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Hynek Schlawack h...@ox.cx added the comment: What's the current state here? Anyone working on a solution or are we waiting how http://hg.python.org/features/pathlib/ will work out? Well, I am not working on that one, so waiting for it to work out might be optimistic :) I don't know what to do with it (the pathlib): is such a feature desireable enough? Independently from this bug, I'd say it would be a good thing. Proof: http://twistedmatrix.com/documents/current/api/twisted.python.filepath.html – Twisted already implemented something similar for themselves. If the consensus is to add a generic walker method, wouldn't be appropriate to open a new bug and add it as dependency? Agreed. See #13734 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13734] Add a generic directory walker method to avoid symlink attacks
New submission from Hynek Schlawack h...@ox.cx: This is an offspring of #4489 (which is a security bug). The method is AFAIU intended to be private. As shown in the discussion of the mentioned #4489, there is a whole family of attacks that exploit the time window between gathering path names and executing a function on them. A general description of this problem can be found in: https://www.securecoding.cert.org/confluence/display/seccode/POS35-C.+Avoid+race+conditions+while+checking+for+the+existence+of+a+symbolic+link While the consequences in rmtree() are probably most dramatic, other recursive functions could benefit too (chmodtree() and chowntree() were mentioned) so Charles-François suggested to write a generic walker method that would take as argument the methods to call on a directory and on a file (or link). Some (probably) necessary helper functions has been already implemented in #4761 (*at()) and #10755 (fdlistdir()). Has there already been done any work? Ross mentioned he wanted to take a stab? -- components: Library (Lib) messages: 150833 nosy: hynek.schlawack, neologix, pitrou, rosslagerwall, tarek priority: normal severity: normal status: open title: Add a generic directory walker method to avoid symlink attacks type: security versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13734 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Glenn Linderman v+pyt...@g.nevcal.com added the comment:
Given Martin's comment (msg150832) I guess I should add my suggestion to this
issue, at least for the record.
Rather than change hash functions, randomization could be added to those dicts
that are subject to attack by wanting to store user-supplied key values. The
list so far seems to be urllib.parse, cgi, json Some have claimed there are
many more, but without enumeration. These three are clearly related to the
documented issue.
The technique would be to wrap dict and add a short random prefix to each key
value, preventing the attacker from supplier keys that are known to collide...
and even if he successfully stumbles on a set that does collide on one request,
it is unlikely to collide on a subsequent request with a different prefix
string.
The technique is fully backward compatible with all applications except those
that contain potential vulnerabilities as described by the researchers. The
technique adds no startup or runtime overhead to any application that doesn't
contain the potential vulnerabilities. Due to the per-request randomization,
the complexity of creating a sequence of sets of keys that may collide is
enormous, and requires that such a set of keys happen to arrive on a request in
the right sequence where the predicted prefix randomization would be used to
cause the collisions to occur. This might be possible on a lightly loaded
system, but is less likely on a system with heavy load, which are more
interesting to attack.
Serhiy Storchaka provided a sample implementation on the python-dev, copied
below, and attached as a file (but is not a patch).
# -*- coding: utf-8 -*-
from collections import MutableMapping
import random
class SafeDict(dict, MutableMapping):
def __init__(self, *args, **kwds):
dict.__init__(self)
self._prefix = str(random.getrandbits(64))
self.update(*args, **kwds)
def clear(self):
dict.clear(self)
self._prefix = str(random.getrandbits(64))
def _safe_key(self, key):
return self._prefix + repr(key), key
def __getitem__(self, key):
try:
return dict.__getitem__(self, self._safe_key(key))
except KeyError as e:
e.args = (key,)
raise e
def __setitem__(self, key, value):
dict.__setitem__(self, self._safe_key(key), value)
def __delitem__(self, key):
try:
dict.__delitem__(self, self._safe_key(key))
except KeyError as e:
e.args = (key,)
raise e
def __iter__(self):
for skey, key in dict.__iter__(self):
yield key
def __contains__(self, key):
return dict.__contains__(self, self._safe_key(key))
setdefault = MutableMapping.setdefault
update = MutableMapping.update
pop = MutableMapping.pop
popitem = MutableMapping.popitem
keys = MutableMapping.keys
values = MutableMapping.values
items = MutableMapping.items
def __repr__(self):
return '{%s}' % ', '.join('%s: %s' % (repr(k), repr(v))
for k, v in self.items())
def copy(self):
return self.__class__(self)
@classmethod
def fromkeys(cls, iterable, value=None):
d = cls()
for key in iterable:
d[key] = value
return d
def __eq__(self, other):
return all(k in other and other[k] == v for k, v in self.items()) and \
all(k in self and self[k] == v for k, v in other.items())
def __ne__(self, other):
return not self == other
--
Added file: http://bugs.python.org/file24169/SafeDict.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Alex Gaynor alex.gay...@gmail.com added the comment: You're seriously underestimating the number of vulnerable dicts. It has nothing to do with the module, and everything to do with the origin of the data. There's tons of user code that's vulnerable too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Alex, I agree the issue has to do with the origin of the data, but the modules listed are the ones that deal with the data supplied by this particular attack. Note that changing the hash algorithm for a persistent process, even though each process may have a different seed or randomized source, allows attacks for the life of that process, if an attack vector can be created during its lifetime. This is not a problem for systems where each request is handled by a different process, but is a problem for systems where processes are long-running and handle many requests. Regarding vulnerable user code, supplying SafeDict (or something similar) in the stdlib or as sample code for use in such cases allows user code to be fixed also. You have entered the class of people that claim lots of vulnerabilities, without enumeration. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13734] Add a generic directory walker method to avoid symlink attacks
Nick Coghlan ncogh...@gmail.com added the comment: I'm working on a library of general directory walking tools that will hopefully make their way back into the stdlib at some point (http://walkdir.readthedocs.org). They're designed to filter and transform the output of os.walk (and similar iterators) in various ways. It may provide a good environment for prototyping a general purpose tree_map for applying an operation to a filesystem tree without being vulnerable to symlink attacks. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13734 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2
Antoine Pitrou pit...@free.fr added the comment: I think OS/2 portability fixes should probably target 3.3 instead. -- nosy: +eric.araujo, loewis, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Paul McMillan p...@mcmillan.ws added the comment: Alex, I agree the issue has to do with the origin of the data, but the modules listed are the ones that deal with the data supplied by this particular attack. They deal directly with the data. Do any of them pass the data further, or does the data stop with them? A short and very incomplete list of vulnerable standard lib modules includes: every single parsing library (json, xml, html, plus all the third party libraries that do that), all of numpy (because it processes data which probably came from a user [yes, integers can trigger the vulnerability]), difflib, the math module, most database adaptors, anything that parses metadata (including commonly used third party libs like PIL), the tarfile lib along with other compressed format handlers, the csv module, robotparser, plistlib, argparse, pretty much everything under the heading of 18. Internet Data Handling (email, mailbox, mimetypes, etc.), 19. Structured Markup Processing Tools, 20. Internet Protocols and Support, 21. Multimedia Services, 22. Internationalization, TKinter, and all the os calls that handle filenames. The list is impossibly large, even if we completely ignore user code. This MUST be fixed at a language level. I challenge you to find me 15 standard lib components that are certain to never handle user-controlled input. Note that changing the hash algorithm for a persistent process, even though each process may have a different seed or randomized source, allows attacks for the life of that process, if an attack vector can be created during its lifetime. This is not a problem for systems where each request is handled by a different process, but is a problem for systems where processes are long-running and handle many requests. This point has been made many times now. I urge you to read the entire thread on the mailing list. Your implementation is impractical because your safe implementation completely ignores all hash caching (each entry must be re-hashed for that dict). Your implementation is still vulnerable in exactly the way you mentioned if you ever have any kind of long-lived dict in your program thread. You have entered the class of people that claim lots of vulnerabilities, without enumeration. I have enumerated. Stop making this argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13735] The protocol 0 of cPickle does not given stable dictionary values
New submission from Kay Hayen kayha...@gmx.de: Hello, I am implementing a Python compiler (Nuitka) that is testing if when it compiles itself, it gives the same output. I have been using protocol = 0 ever since with pickle module for historic reasons (gcc bug with raw strings lead me to believe it's better) and lately, I have changed to protocol = 2 and cPickle. But then I noticed that my compile itself test now fail to give same code from pickling of dictionary constants. Imanaged and isolated the issue, and it's a Python2.7 regression, Python2.6 is fine: Observe this output from cPickle.dumps for a constant dictionary with one element: Protocol 0 : Dumping read const const stream (dp1\nS'modules'\np2\nNs. Dumping load const const stream (dp1\nS'modules'\np2\nNs. Dumping load const const stream (dp1\nS'modules'\np2\nNs. Protocol 1 : Dumping read const const stream '}q\x01U\x07modulesq\x02Ns.' Dumping load const const stream '}q\x01U\x07modulesNs.' Dumping load const const stream '}q\x01U\x07modulesNs.' Protocol 2 : Dumping read const const stream '\x80\x02}q\x01U\x07modulesq\x02Ns.' Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.' Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.' It seems that cPickle as of CPython2.7 does give a better stream for dictionaries it itself emitted. With CPython2.6 I observe no difference. My work-around is to re-stream, dumps - loads - dumps with CPython2.7 for the time being. Can you either: Fix cPickle to treat the dictionaries the same, or enhance to core to produce the same dict as cPickle does? It appears at least some kind of efficiency might be missed out for marshall as well. -- components: Interpreter Core, Library (Lib) files: stream.py messages: 150841 nosy: kayhayen priority: normal severity: normal status: open title: The protocol 0 of cPickle does not given stable dictionary values type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file24170/stream.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2
Martin v. Löwis mar...@v.loewis.de added the comment: Paul, can you please elaborate on the patch? The original code looks better to me than the new code. Why do you think this change is right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2
Paul Smedley p...@smedley.id.au added the comment: I'm building OS/2 python here using configure, etc - without the changes attached, python would not complete the build. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12736] Request for python casemapping functions to use full not simple casemaps per Unicode's recommendation
Benjamin Peterson benja...@python.org added the comment: Here is a patch. I only dealt with case mappings and not titlecase. Doing titlecase properly requires word segmentation, which I think should be another patch/issue. This patch fixes swapcase(), capitalize(), upper(), and lower(). It does not include the changes to Objects/unicodetype_db.h because those are huge. Regenerate the database if you want to test it. Please review. -- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file24171/full-casemapping.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13734] Add a generic directory walker method to avoid symlink attacks
Ross Lagerwall rosslagerw...@gmail.com added the comment: Has there already been done any work? Ross mentioned he wanted to take a stab? Unfortunately, I'm rather busy at the moment but when I get some free time and if no one else wants to work on it then I'll take a look. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13734 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Glenn Linderman v+pyt...@g.nevcal.com added the comment: [offlist] Paul, thanks for the enumeration and response. Some folks have more experience, but the rest of us need to learn. Having the proposal in the ticket, with an explanation of its deficiencies is not all bad, however, others can learn, perhaps. On the other hand, I'm willing to learn more, if you are willing to address my concerns below. I had read the whole thread and issue, but it still seemed like a leap of faith to conclude that the only, or at least best, solution is changing the hash. Yet, changing the hash still doesn't seem like a sufficient solution, due to long-lived processes. On 1/7/2012 6:40 PM, Paul McMillan wrote: Paul McMillanp...@mcmillan.ws added the comment: Alex, I agree the issue has to do with the origin of the data, but the modules listed are the ones that deal with the data supplied by this particular attack. They deal directly with the data. Do any of them pass the data further, or does the data stop with them? For web forms and requests, which is the claimed vulnerability, I would expect that most of them do not pass the data further, without validation or selection, and it is unlikely that the form is actually expecting data with colliding strings, so it seems very unlikely that they would be passed on. At least that is how I code my web apps: just select the data I expect from my form. At present I do not reject data I do not expect, but I'll have to consider either using SafeDict (which I can start using ASAP, not waiting for a new release of Perl to be installed on my Web Server (currently running Perl 2.4), or rejecting data I do not expect prior to putting it in a dict. That might require tweaking urllib.parse a bit, or cgi, or both. A short and very incomplete list of vulnerable standard lib modules includes: every single parsing library (json, xml, html, plus all the third party libraries that do that), all of numpy (because it processes data which probably came from a user [yes, integers can trigger the vulnerability]), difflib, the math module, most database adaptors, anything that parses metadata (including commonly used third party libs like PIL), the tarfile lib along with other compressed format handlers, the csv module, robotparser, plistlib, argparse, pretty much everything under the heading of 18. Internet Data Handling (email, mailbox, mimetypes, etc.), 19. Structured Markup Processing Tools, 20. Internet Protocols and Support, 21. Multimedia Services, 22. Internationalization, TKinter, and all the os calls that handle filenames. The list is impossibly large, even if we completely ignore user code. This MUST be fixed at a language level. I challenge you to find me 15 standard lib components that are certain to never handle user-controlled input. I do appreciate your enumeration, but I'll decline the challenge. While all of them can be interesting exploits of naïve applications (written by programmers who may be quite experienced in some things, but can naïvely overlook other things), most of them probably do not apply to the documented vulnerability. Many I had thought of, but rejected for this context; some I had not. So while there are many possible situations where happily stuffing things into a dict may be an easy solution, there are many possible cases where it should be prechecked on the way in. And there is another restriction: if the user-controlled input enters a user-run program, it is unlikely to be attacked in the same manner than web servers are attacked. A user, for example, is unlikely to contrive colliding file names for the purpose of making his file listing program run slow. So it is really system services and web services that need to be particularly careful. Randomizing the hash seed might reduce the problem from any system/web services to only long-running system/web services, but doesn't really solve the complete problem, as far as I can tell... only proper care in writing the application (and the stdlib code) will solve the complete problem. Sadly, beefing up the stdlib code will probably reduce performance for things that will not be exploited to be careful enough in the cases that could be exploited. Note that changing the hash algorithm for a persistent process, even though each process may have a different seed or randomized source, allows attacks for the life of that process, if an attack vector can be created during its lifetime. This is not a problem for systems where each request is handled by a different process, but is a problem for systems where processes are long-running and handle many requests. This point has been made many times now. I urge you to read the entire thread on the mailing list. Your implementation is impractical because your safe implementation completely ignores all hash caching (each entry must be re-hashed for that dict). Your implementation is still
[issue13703] Hash collision security issue
Christian Heimes li...@cheimes.de added the comment: Glenn, you have reached a point where you stop bike-shedding and start to troll by attacking people. Please calm down. I'm sure that you are just worried about the future of Python and all the bad things, that might be introduced by a fix for the issue. Please trust us! Paul, Victor, Antoine and several more involved developers are professional Python devs and have been for years. Most of them do Python development for a living. We won't kill the snake that pays our bills. ;) Ultimately it's Guido's choice, too. Martin: Ouch, the startup impact is large! Have we reached a point where one size fits all doesn't work any longer? It's getting harder to have just one executable for 500ms scripts and server processes that last for weeks. Marc-Andre: Have you profiled your suggestion? I'm interested in the speed implications. My gut feeling is that your idea could be slower, since you have added more instructions to a tight loop, that is execute on every lookup, insert, update and deletion of a dict key. The hash modification could have a smaller impact, since the hash is cached. I'm merely speculating here until we have some numbers to compare. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Glenn Linderman v+pyt...@g.nevcal.com added the comment: I don't find a way to delete my prior comment, so I'll add one more (only). The prior comment was intended to go to one person, but I didn't notice the From, having one person's name, actually went back to the ticket (the email address not being for that individual), now I do, so I've learned that. My prior comment was a request for further explanation of things I still don't understand, not intended to be an attack. If someone can delete both this and my prior comment from the issue, or tell me how, feel free. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4489] shutil.rmtree is vulnerable to a symlink attack
Changes by Ross Lagerwall rosslagerw...@gmail.com: -- dependencies: +Add a generic directory walker method to avoid symlink attacks ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client
New submission from Jyotirmoy Bhattacharya jyotir...@jyotirmoy.net: The documentation for urlopen says that it raises URLError on error. But there exist error conditions such as a socket timeout or a bad HTTP status line under which the exception from the underlying library leaks through urllib, thus breaking the promise in the documentation. I am attaching a test program that demonstrates this bug. -- components: Library (Lib) files: test_urllib_except.py messages: 150849 nosy: jmoy, orsenthil priority: normal severity: normal status: open title: urllib.request.urlopen leaks exceptions from socket and httplib.client versions: Python 3.3 Added file: http://bugs.python.org/file24172/test_urllib_except.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client
Jyotirmoy Bhattacharya jyotir...@jyotirmoy.net added the comment: A patch to fix this issue. Catches exceptions from underlying libraries and reraises them as URLError. I put the class name of the underlying exception in the reason to make it more descriptive. -- keywords: +patch type: - behavior Added file: http://bugs.python.org/file24173/urllib_exception_leak.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12364] Deadlock in test_concurrent_futures
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 26389e9efa9c by Ross Lagerwall in branch '3.2': Issue #12364: Fix a hang in concurrent.futures.ProcessPoolExecutor. http://hg.python.org/cpython/rev/26389e9efa9c New changeset 25f879011102 by Ross Lagerwall in branch 'default': Merge with 3.2 for #12364. http://hg.python.org/cpython/rev/25f879011102 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12364 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13737] bugs.python.org's Django settings file DEBUG=True
New submission from Bithin A bithin2...@gmail.com: I am getting an Django error when I was trying to review a patch. This error has occurred in the site as the DEBUG mode in the Django settings file is set to True. It is a security issue and should be set to false. I am attaching the screen shot of the error which I have come across. -- components: None files: Screenshot at 2012-01-08 13:11:43.png messages: 150852 nosy: Bithin.A priority: normal severity: normal status: open title: bugs.python.org's Django settings file DEBUG=True type: security Added file: http://bugs.python.org/file24174/Screenshot at 2012-01-08 13:11:43.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13737 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
