[issue15061] hmac.secure_compare() leaks information about length of strings
Hynek Schlawack h...@ox.cx added the comment: Secure vs not secure is not a binary state - it's about making attacks progressively more difficult. Something that is secure against a casual script kiddie scatter gunning attacks on various sites with an automated script won't stand up to a systematic attack from a motivated attacker (also see the reporting on Flame and Stuxnet for what a *really* motivated and well resourced attacker can achieve). The problem here is, that _if_ you add a secure to the name of a method, it becomes binary. At least in the minds of the users. I know you address that, but that's the main point here. Regardless, the target needs to be *improving the status quo*. Being able to tell people using hmac.total_compare will make you less vulnerable to timing attacks than using ordinary short circuiting comparisons is a *good thing*. We just need to be careful not to oversell it as making you *immune* to timing attacks. Why not write a C function which can be more secure than Python code? I would argue that would be an general asset for the stdlib, not just for HMAC (therefore, I'd put it elsewhere). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: On 14.06.2012 14:26, Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: It's either secure or it's not. I don't think that's true. By that reasoning, Python is not secure so there's no point in fixing crashes or providing a hashlib module. The proper statement is It's either time-independent or it's not. This *is* a binary state (I agree that being secure is not a binary state). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: Being able to tell people using hmac.total_compare will make you less vulnerable to timing attacks than using ordinary short circuiting comparisons is a *good thing*. No, it's not. It's a *bad thing*. The two issues that have been opened since the function was first submitted indicate that people will keep inspecting the code and find out that it's not time-independent. If they had been relying on that it is, they will be upset. Since it's inherently impossible to make the function time-independent, people will be constantly annoyed about this function. I can't find anything good in that. If nobody else does, I'll revert the addition before the beta. Note that there is no *actual* issue that is being resolved by this function; it was added only because of its cuteness value. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: Why not write a C function which can be more secure than Python code? For Unicode strings, it's impossible to write a time-independent comparison function even in C I would argue that would be an general asset for the stdlib I would argue that it's not. No actual use case for this function has been demonstrated so far. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing
Serhiy Storchaka storch...@gmail.com added the comment: xml.sax.saxutils.XMLGenerator constructor has a parameter short_empty_elements (False by default). For consistency new ElementTree.write parameter must have the same name (True by default for compatibility). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14377 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Hynek Schlawack h...@ox.cx added the comment: Why not write a C function which can be more secure than Python code? For Unicode strings, it's impossible to write a time-independent comparison function even in C Really? Some comments sounded different. That's too bad but also what I suspected in the first place – it seems to complex. However, this function seems only useful to bytes anyway so why not strip it down if it _is_ possible with bytes? Am I missing something? I would argue that would be an general asset for the stdlib I would argue that it's not. No actual use case for this function has been demonstrated so far. Well, one example: https://github.com/mitsuhiko/python-pbkdf2/blob/master/pbkdf2.py and any other place that compares passwords, tokens, … -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Serhiy Storchaka storch...@gmail.com added the comment: The patch updated to reflect Martin's comments. I hope the old behavior now preserved in the most used in practice cases. Tests converted to work with bytes instead of strings. -- Added file: http://bugs.python.org/file26011/XMLGenerator-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1470548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14035] behavior of test.support.import_fresh_module
Changes by Nick Coghlan ncogh...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14035 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: Can people please stop raising a false dichotomy and using that as an excuse not to do anything? The decision is not between leak some information and leak no information. It is between leak more information and leak less information. The timing variations with standard comparison are relatively massive and relatively easy to analyse (if the time taken goes up, you got the previous digit correct). With this comparison, they're far more subtle and require much greater analysis to figure out the significance of the timing changes. That reduces the pool of attackers to those capable of performing that analysis (or in possession of tools that will perform that analysis for them). Yes, the docs and name are currently completely unacceptable. But scorched earth is not a good answer, because that just means people will fall back to using == which is *even worse* from a security point of view. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: Well, one example: https://github.com/mitsuhiko/python-pbkdf2/blob/master/pbkdf2.py It says that it needs that, but I fail to understand why. pbkdf2 is used to generate encryption keys from passwords, where you don't need to compare strings at all. Instead, you derive a key from the password, and use the key e.g. for AES encryption. If you use pdkdf2 for password hashing, then you do need a comparison function, but it's irrelevant whether that is time-independent. If an attacker was able to determine that his hash brings him close to the actual hash, this is no gain in cracking - since similar hashes do not at all mean that the passwords are similar. and any other place that compares passwords, tokens, … No no no. Any sensible place to compare passwords would use some sort of one-way function (password hash) before the comparison, so that someone breaking into the machine will not gain the clear text passwords. As a side effect, timing attacks become futile, since hash functions provide confusion and diffusion, so if a timing attack detects that it found a key that hashes similar to the real key, that doesn't get it any closer to revealing the real key. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15074] Strange behaviour of python cmd module. (Ignores slash)
New submission from jsevilleja j...@jsevilleja.org: I've used the code from here: http://stackoverflow.com/questions/5637124/tab-completion-in-pythons-raw-input/5638688#5638688 and it works. But I've used the same code in a class which inherits from cmd.Cmd, and the code doesn't works. Doing tests, I've noticed that if I do put /, the argument text from complete_put method, skips '/' character. I don't know if this is a bug or my code is wrong, but it works with any other character, and I haven't found anything in the docs. Thanks. -- files: shell.py messages: 162854 nosy: jsevilleja priority: normal severity: normal status: open title: Strange behaviour of python cmd module. (Ignores slash) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26012/shell.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: To repeat, the specific feature being proposed for retention is: * a function called hmac.total_compare() that is clearly documented as being still vulnerable to timing analysis given a sufficiently sophisticated attacker, while still being more resistant to such analysis than the standard comparison operator * restricting that function to operating on bytes, to eliminate timing variations associated with encoding/decoding of Unicode text and reduce those associated with the calculation of integer values Leaking less information on each comparison is intended to increase the effectiveness of higher level timing attack countermeasures (such as rate limiting and lockouts). Anyone that would use hmac.total_compare and call it done is likely using ordinary comparison today (which is even worse). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: The timing variations with standard comparison are relatively massive and relatively easy to analyse (if the time taken goes up, you got the previous digit correct). If you have an application that is vulnerable to such an attack, you better reconsider your entire approach, rather than using a library function that says it will harden your approach (but may actually not). Yes, the docs and name are currently completely unacceptable. But scorched earth is not a good answer, because that just means people will fall back to using == which is *even worse* from a security point of view. It's not scorched earth. It's the standard procedure for adding features to the standard library. *At a minimum* there needs to be a use case, which has not been demonstrated yet (the OP of the original report thought he had a use case, but then agreed that he was wrong). Then, the use case should be fairly relevant for inclusion in the standard library. I wish there was an AES implementation in the library before we start worrying about stuff like this. Then, ideally, the new library function has been in wide use for some time. This was rushed, and it needs to be reverted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: To repeat, the specific feature being proposed for retention is: To repeat, no use case has been demonstrated for that function. It has been added because it was fun to write, not because it is useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski fij...@gmail.com added the comment: On Fri, Jun 15, 2012 at 9:41 AM, Nick Coghlan rep...@bugs.python.orgwrote: Nick Coghlan ncogh...@gmail.com added the comment: To repeat, the specific feature being proposed for retention is: * a function called hmac.total_compare() that is clearly documented as being still vulnerable to timing analysis given a sufficiently sophisticated attacker, while still being more resistant to such analysis than the standard comparison operator * restricting that function to operating on bytes, to eliminate timing variations associated with encoding/decoding of Unicode text and reduce those associated with the calculation of integer values Leaking less information on each comparison is intended to increase the effectiveness of higher level timing attack countermeasures (such as rate limiting and lockouts). Anyone that would use hmac.total_compare and call it done is likely using ordinary comparison today (which is even worse). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ Nick, I fail to understand why are you opposing writing such a function in C. Such a function can be provably time-independent (and as MvL says this is a binary state), at least as long as it operates on bytes (I'll refrain from asking about unicode, I think it's possible, but I dunno). For the same function in python it's at the very least much harder to prove (and has bugs as we've seen) Cheers, fijal -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski fij...@gmail.com added the comment: On Fri, Jun 15, 2012 at 9:47 AM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: To repeat, the specific feature being proposed for retention is: To repeat, no use case has been demonstrated for that function. It has been added because it was fun to write, not because it is useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ Is comparing passwords against a secure one not useful? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Hynek Schlawack h...@ox.cx added the comment: and any other place that compares passwords, tokens, … No no no. Any sensible place to compare passwords would use some sort of one-way function (password hash) before the comparison, so that someone breaking into the machine will not gain the clear text passwords. I agree that this is the right way to do. However I disagree that it's also the only sensible way to do in the real world. Sometimes you just _have_ to compare sensitive strings, whether you like it or not. I see your point that adding such a function would leverage bad security behavior and thus may be a bad thing. The usefulness of such a function to some(?) people is IMHO not disputable though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: I'm not really opposed to writing it in C - I just don't think rewriting it in C should be a requirement for keeping it. Even in pure Python, it still leaks less information than the standard comparison operator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski fij...@gmail.com added the comment: On Fri, Jun 15, 2012 at 9:55 AM, Hynek Schlawack rep...@bugs.python.orgwrote: Hynek Schlawack h...@ox.cx added the comment: and any other place that compares passwords, tokens, … No no no. Any sensible place to compare passwords would use some sort of one-way function (password hash) before the comparison, so that someone breaking into the machine will not gain the clear text passwords. I agree that this is the right way to do. However I disagree that it's also the only sensible way to do in the real world. Sometimes you just _have_ to compare sensitive strings, whether you like it or not. I see your point that adding such a function would leverage bad security behavior and thus may be a bad thing. The usefulness of such a function to some(?) people is IMHO not disputable though. Note that this does not relief you from using a time-independent comparison function. If you call some hash function (which time is known to the attacker), then you compare it against a stored hashed version. If you use a normal compare you're leaking the hash. This is indeed not as bad as leaking the password, but it has been demonstrated that one-direction functions are still vulnerable to some sort of attacks, so it's not ideal either. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: Is comparing passwords against a secure one not useful? I claim that this use case doesn't occur in practice. Everybody uses hashed passwords. If they do compare against a plain-text password, and they want to change something about it, they should switch to hashed passwords. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: This point was discussed in #14532 when the new API was added. From http://bugs.python.org/issue14532#msg158045: Given that this issue has affected a lot of security-sensitive third-party code (keyczar, openid providers, almost every python web service that implements secure cookies [1] or other HMAC-based REST API signatures), I do like the idea of adding a warning in the relevant documentation as sbt proposed. The only reason I'd recommend _not_ putting a time_independent_comparison() function in the hmac module is that it's not really HMAC-specific. In practice, any fixed-length secrets should be compared in a time-independent manner. It just happens that HMAC verification is a pretty common case for this vulnerable construct. :-) For password hashing, the attacker is unlikely to be able to provide the digest directly, but for signature checking it's far more likely to be the case. The idea is to make it easy for people to reduce the time variance of their digest comparisons as the *default* choice when writing security related code. Deciding whether or not the risk of a timing attack is actually significant requires you to look at the system as a whole and decide Oh, OK, shortcircuiting comparison doesn't leave us open to timing analysis here, we can use it as a performance enhancement. (Although, in most systems, there are likely to be plenty of other less sensitive places to go after for performance improvements first) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14991] Option for regex groupdict() to show only matching names
Changes by Ezio Melotti ezio.melo...@gmail.com: -- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: I see your point that adding such a function would leverage bad security behavior and thus may be a bad thing. The usefulness of such a function to some(?) people is IMHO not disputable though. I think this entire issue is out of scale. There is really bigger fish to fry. The two people who really need this should post a package to PyPI. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15007] Unittest CLI does not support test packages very well
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15019] String termination on Linux
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15019 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15034] tutorial should use best practices in user defined exceptions section
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15034 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14998] pprint._safe_key is not always safe enough
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15009] urlsplit can't round-trip relative-host urls.
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - needs patch type: - behavior versions: +Python 3.3 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: Note that this does not relief you from using a time-independent comparison function. If you call some hash function (which time is known to the attacker), then you compare it against a stored hashed version. If you use a normal compare you're leaking the hash. This is indeed not as bad as leaking the password, but it has been demonstrated that one-direction functions are still vulnerable to some sort of attacks, so it's not ideal either. But you don't leak the hash - you leak the first byte of the hash if you make 256 tries, and the first two bytes if you make 65536 tries. To leak the first four bytes of the hash, you need to make 2**32 tries. So this is equivalent to a brute-force attack, which works just as well against a time-independent function. So using a time-independent function does not add any security. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Maciej Fijalkowski fij...@gmail.com added the comment: On Fri, Jun 15, 2012 at 10:09 AM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: Note that this does not relief you from using a time-independent comparison function. If you call some hash function (which time is known to the attacker), then you compare it against a stored hashed version. If you use a normal compare you're leaking the hash. This is indeed not as bad as leaking the password, but it has been demonstrated that one-direction functions are still vulnerable to some sort of attacks, so it's not ideal either. But you don't leak the hash - you leak the first byte of the hash if you make 256 tries, and the first two bytes if you make 65536 tries. To leak the first four bytes of the hash, you need to make 2**32 tries. So this is equivalent to a brute-force attack, which works just as well against a time-independent function. So using a time-independent function does not add any security. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ Martin, you fail to understand how this works. You don't do 2**32 tries to leak the 4 charaters, you need 4 * 256, that's why this attack is so bad, because the time needed for the next character is brute force, but then you can move on to the next one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: For password hashing, the attacker is unlikely to be able to provide the digest directly, but for signature checking it's far more likely to be the case. Can you elaborate? What is the application, where is the digest checking, and what is the threat? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11600] PY_CFLAGS and PY_CPPFLAGS inconsistent
Serhiy Storchaka storch...@gmail.com added the comment: PY_CFLAGS (C compiler flags) always used with PY_CPPFLAGS (C preprocessor flags). The include directories need for #include, so it is logical that PY_CPPFLAGS did contain them. This may be useful if you use C preprocessor without C compiler. I don't think that this is a regression. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15075] XincludeTest failure in test_xml_etree
New submission from Eli Bendersky eli...@gmail.com: The XincludeTest test-case in test_xml_etree is now skipped, because it fails in an intermittent manner. I can reproduce the failure when running full regrtest with -j1, but not -j8, and not when run individually. The failure is most likely due to the test itself, in the way it imports the Python ET, leaving _elementtree out. This may be related to http://bugs.python.org/issue14035 -- components: Tests messages: 162870 nosy: eli.bendersky, flox priority: normal severity: normal stage: test needed status: open title: XincludeTest failure in test_xml_etree type: crash versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: Martin, you fail to understand how this works. You don't do 2**32 tries to leak the 4 charaters, you need 4 * 256, that's why this attack is so bad, because the time needed for the next character is brute force, but then you can move on to the next one. How so? Assume we have a hashed password, and assume we have somehow guessed the first three bytes. How can I then find out the fourth byte in only 256 tries? I would have to generate passwords whose *hash* matches in the first three bytes. This is not feasible, for any hash function that is worth its salt. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: That's why the vulnerable cases are far more likely to be related to *signature* checking. In those you can generally provide both the hash input (the message) and the hash target (the purported signature). If the signature check uses a time-dependent comparison that exhibits a lot of externally visible variance, then you can use a timing attack to find the signature that corresponds to a particular message (by keeping the message constant and changing the signature). Depending on the nature of the message, you're potentially done at that point (since on your final attempt your signed message was accepted), or else you may be after data that you can feed into an analysis aimed at breaking the signing key itself (a much harder prospect, but still possible given a sufficiently large sample, or a signing algorithm that is vulnerable to leaking the key as a result of chosen plaintext attacks). Yes, system level defences are also important (that's why multiprocessing turned out to not, in fact, be vulnerable to an attack based on time dependent signature comparisons), but minimising information leakage is just a good principle of secure design. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15075] XincludeTest failure in test_xml_etree
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Petri Lehtinen pe...@digip.org added the comment: For example, Django uses time independent comparison to compare signatures of signed cookies. A signed cookie consists of a plain-text value followed by a signature. An attacker wants to construct a cookie that has a malformed value and a valid signature for that value. Let's assume that a signature is a string of 16 hex characters. If a short-cut comparison was used, the attacker would require at most 16 tries to find out the first character. He first tries the signature 000...0, then 100...0, and so on until he notices that Django takes a slightly longer time to respond. Now he know what's the first character of the hash, let's assume it's 8. He then tries 8000...0, 810...0, and so on until he finds the second character. He continues this until he has the correct 16 characters. This takes at most 16 * 16 tries. But because Django uses a constant-time comparison function, the attacker cannot guess one character at a time, and he needs 16 ** 16 tries. In real world, 16 * 16 tries is not enough, of course. But repeating the same requests many times, the timing variations can be used to reveal which is the correct character in each step. -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15073] commands.getoutput() is broken
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: The documentation http://docs.python.org/library/commands.html prominently says Platforms: Unix. This module does not work on Windows. You should really use the subprocess module: import subprocess output = subprocess.check_output(dir, shell=True) -- nosy: +amaury.forgeotdarc resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: FWIW, Petri's example also explains why leaking the expected length of the string is considered an acceptable optimisation in most reimplementations of this signature check comparison: the attacker is assumed to already know the expected length of the signature, because it's part of a documented protocol or API. However, I think it's more reasonable for a standard library implementation to omit that optimisation by default. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12508] Codecs Anomaly
Changes by Serhiy Storchaka storch...@gmail.com: -- versions: +Python 2.7, Python 3.3 Added file: http://bugs.python.org/file26013/fffd-2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598083] Top-level exception handler writes to stdout unsafely
Serhiy Storchaka storch...@gmail.com added the comment: It looks like another reason to replace codecs.open on io.open. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1598083 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Martin v. Löwis mar...@v.loewis.de added the comment: That's why the vulnerable cases are far more likely to be related to *signature* checking. In those you can generally provide both the hash input (the message) and the hash target (the purported signature). I see. I wonder how feasible this attack is, though, since the signature validation involves a lot of computation (including hashing the original message), of which comparing the signature values is but a tiny step. In addition, for public-key signatures (RSA and DSA), I fail to see the threat. I can verify the signature offline, so I don't need to rely on timing attacks to find out what the correct signature would be. Plus I still need to brute-force the signatures, whether for offline generation, or in the timing attack, because it's *not* the case that the expected signature gets compared with the provided signature. Instead, something derived from the message gets compared with something derived from the purported signature. It's really only HMAC which may be vulnerable. In http://seb.dbzteam.org/crypto/python-oauth-timing-hmac.pdf the author discusses that the real protection against this attack is to fix the actual bugs in the OAuth implementation (when OAuth is designed to prevent replay attacks which would also prevent this attack). In the end, he claims that using time-independent comparison would add even more security, but in the same hand-waving fashion shown in this issue (i.e. without providing any proof that his proposed attack actually works - which I claim it won't, due to the noise caused by the HMAC generation). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5067] Error msg from using wrong quotes in JSON is unhelpful
Serhiy Storchaka storch...@gmail.com added the comment: Patch adapted for Python 3.3. Consistently changed messages in C code, docs and docstrings. -- components: +Documentation nosy: +storchaka versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 Added file: http://bugs.python.org/file26014/json-messages-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Changes by Armin Rigo ar...@users.sourceforge.net: -- nosy: -arigo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback
New submission from Leon Zhang leozh...@cisco.com: Hello Experts, I am using Python 2.6.2 on a Linux machine. I found sometimes I have problem to run my simple python script. Linux version and Python version leonz@fxcsgbu2c1% uname -a SunOS fxcsgbu2c1 5.8 Generic_117350-06 sun4u sparc SUNW,UltraAX-i2 leonz@fxcsgbu2c1% python Python 2.6.2 (r262:71600, Sep 9 2009, 06:36:48) [GCC 3.4.6] on sunos5 Type help, copyright, credits or license for more information. Problem description I have one python script file located at /usr/autoprog/LogUtility/pygen.py, the first 4 lines are: line 1: #!/usr/bin/python line 2: import sys line 3: import os line 4: import traceback If I just run python /usr/autoprog/LogUtility/pygen.py from shell, the script always worked fine. We are running another application called autotest on this machine, autotest will create a new process and launch Python in this new process (/usr/bin/python /usr/autoprog/LogUtility/pygen.py) to run my Python script. Most of the time, the Python script worked fine, but from some time, for some reason, the script suddenty failed, and from this time, if I run autotest to luanch my python script, it always fails, but if I run the python script from shell, it always works fine. If I reboot this machine, both way to run python script works fine. But after some time, run autotest to luanch python script will fail again... Here is the details of the error message of running autotest to luanch python script: 'import site' failed; use -v for traceback Traceback (most recent call last): File /usr/autoprog/SGBU/LogUtility/pygen.py, line 19, in module import os File /usr/local/lib/python2.6/os.py, line 49, in module import posixpath as path File /usr/local/lib/python2.6/posixpath.py, line 16, in module import warnings File /usr/local/lib/python2.6/warnings.py, line 6, in module import linecache ImportError: No module named linecache Some other information may help I had searched 'import site' failed; use -v for traceback on internet, there are also many other people have this problem, but I didn't see any useful information to fix my problem. Here are some information about the Python on my machine: Install path is /usr/local/lib/python2.6 There is just one README file under /usr/local/lib/python2.6/site-packages Attached is the python script file pygen.py. Could any expert help me on this problem? Appreciate if any experts can reply me. Thanks. -- components: Library (Lib) files: pygen.py messages: 162879 nosy: qtld614 priority: normal severity: normal status: open title: Sometimes couldn't import os, shown 'import site' failed, use -v for trackback type: crash versions: Python 2.6 Added file: http://bugs.python.org/file26015/pygen.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Christian Heimes li...@cheimes.de added the comment: Oh dead god, what have I done ... I threw a small stone and caused a major landslide. :) I'm all with Nick on this topic. A correctly named and documented function provides a tool to users that greatly reduced the change of a side channel attack. It's all about teaching good practice. I also agree that we must neither call it 'secure' nor documented it as 'secure'. I believe the correct term is 'hardened against timing analysis and side channel attacks' I could wrap up a quick C implementation if you like. The operator module is a better place for a total_compare() function. Do you a agree? I recommend that you read/watch Geremy Condra's PyCon talk Through the Side Channel: Timing and Implementation Attacks in Python. The slides contain timing analysis diagrams. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15075] XincludeTest failure in test_xml_etree
Eli Bendersky eli...@gmail.com added the comment: After some tinkering I found which test when run before test_xml_etree causes it to crash: $ ./python -m test.regrtest test___all__ test_xml_etree [1/2] test___all__ [2/2] test_xml_etree Fatal Python error: Segmentation fault Current thread 0x7f771ecec700: File /home/eliben/python-src/33/Lib/xml/etree/ElementTree.py, line 895 in _namespaces File /home/eliben/python-src/33/Lib/xml/etree/ElementTree.py, line 843 in write File /home/eliben/python-src/33/Lib/test/test_xml_etree.py, line 103 in serialize File /home/eliben/python-src/33/Lib/test/test_xml_etree.py, line 2020 in test_xinclude_default File /home/eliben/python-src/33/Lib/unittest/case.py, line 385 in _executeTestPart File /home/eliben/python-src/33/Lib/unittest/case.py, line 440 in run File /home/eliben/python-src/33/Lib/unittest/case.py, line 492 in __call__ File /home/eliben/python-src/33/Lib/unittest/suite.py, line 105 in run File /home/eliben/python-src/33/Lib/unittest/suite.py, line 67 in __call__ File /home/eliben/python-src/33/Lib/unittest/suite.py, line 105 in run File /home/eliben/python-src/33/Lib/unittest/suite.py, line 67 in __call__ File /home/eliben/python-src/33/Lib/test/support.py, line 1282 in run File /home/eliben/python-src/33/Lib/test/support.py, line 1383 in _run_suite File /home/eliben/python-src/33/Lib/test/support.py, line 1417 in run_unittest File /home/eliben/python-src/33/Lib/test/test_xml_etree.py, line 2311 in test_main File /home/eliben/python-src/33/Lib/test/regrtest.py, line 1238 in runtest_inner File /home/eliben/python-src/33/Lib/test/regrtest.py, line 919 in runtest File /home/eliben/python-src/33/Lib/test/regrtest.py, line 710 in main File /home/eliben/python-src/33/Lib/test/regrtest.py, line 1829 in module File /home/eliben/python-src/33/Lib/runpy.py, line 75 in _run_code File /home/eliben/python-src/33/Lib/runpy.py, line 162 in _run_module_as_main Segmentation fault (core dumped) Note that this is the Python test crashing. test_xml_etree_c works fine -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Antoine Pitrou pit...@free.fr added the comment: I could wrap up a quick C implementation if you like. The operator module is a better place for a total_compare() function. Do you a agree? I think the function is fine in either hashlib or hmac. Putting it in one of these modules is a hint that it's security-related. On the other hand, linking to it from these modules' documentations is just as fine, if it is put in the operator module. If you make a C implementation, it could also be interesting to cover the pure-ASCII unicode case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15077] Regexp match goes into infinite loop
New submission from Moriyoshi Koizumi mozo+pyt...@mozo.jp: A peculiar pair of a regexp and a target string causes the runtime into an infinite loop. The same expression works with Perl. -- components: Regular Expressions files: x.py messages: 162883 nosy: ezio.melotti, moriyoshi, mrabarnett priority: normal severity: normal status: open title: Regexp match goes into infinite loop type: crash versions: Python 2.7 Added file: http://bugs.python.org/file26016/x.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15075] XincludeTest failure in test_xml_etree
Eli Bendersky eli...@gmail.com added the comment: As suspected, the cause is that xinclude_loader manages to somehow import the C version of ET, although test_xml_etree tries to enforce the Python version. This is probably because test___all__ imports all modules and leaves stuff in the import cache. What causes the segfault itself is that C Elements are mixed with Python Elements, and they're incompatible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: As a first step, I'm going to make a change to: 1. Rename the function to compare_digest 2. Remove the support for comparing strings 3. Update the documentation to be much clearer about its limitations (including why it's considered OK to leak the expected length of the digest) If a C implemented operator.total_compare is made available, then hmac.compare_digest could be updated to use it (retaining the length shortcircuiting behaviour) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15078] Change os.sendfile so its arguments are stable
New submission from Larry Hastings la...@hastings.org: As I keep saying on python-dev: I think that the argument list for a function should be stable. If you have a function where some abilities are only available on certain platforms, it's best to always accept default no-op parameters for those parameters, rather than adding and removing parameters based on what functionality is available. os.sendfile() accepts either four or seven parameters, depending on the current platform. However, it's a new function in trunk and therefore has no installed base. So it's not too late to change it. I propose to amend os.sendfile so it always accepts all seven arguments. Its signature would therefore be the following, on all platforms: os.sendfile(out, in, offset, nbytes, headers=None, trailers=None, flags=0) Passing in a non-None value for headers or trailers, or a nonzero value for flags, on a platform where the seven-argument form of sendfile is not available would raise NotImplementedError. -- assignee: larry messages: 162886 nosy: larry priority: normal severity: normal status: open title: Change os.sendfile so its arguments are stable type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14423] Getting the starting date of iso week from a week number and a year.
Erik Cederstrand e...@cederstrand.dk added the comment: I would like to point out that http://bugs.python.org/issue12006 provides a solution (including patches) based on %G%, V and %u directives for use in strptime()/strftime(). These directives are defined in (FreeBSD) libc, and PHP has them, too. I think the strptime approach is a more elegant and standardized way of creating dates from exotic values. -- nosy: +Erik Cederstrand ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset f36af3766a20 by Nick Coghlan in branch 'default': Issue #15061: Don't oversell the capabilities of the new non-shortcircuiting comparison function in hmac http://hg.python.org/cpython/rev/f36af3766a20 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14955] hmac.secure_compare() is not time-independent for unicode strings
Nick Coghlan ncogh...@gmail.com added the comment: As a result of the discussions on #15061, I removed unicode comparison support altogether in f36af3766a20 (updating the warning on the hexdigest() method accordingly). Are folks happy to close this issue on that basis? (I'll raise the question of a separate C implementation on the other issue) -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15036] mailbox.mbox fails to pop two items in a row, flushing in between
Petri Lehtinen pe...@digip.org added the comment: As I suspected, all single-file mailboxes(mbox, MMDF, Babyl) have this issue. Attached a patch with tests. -- keywords: +patch Added file: http://bugs.python.org/file26017/issue15036.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: OK, the worst aspects (the misleading name and documentation) have been dealt with, so that leaves the questions of: 1. Avoiding leaking the length information (seems unnecessary, since most digests are part of protocols where they have a known, published length, or you can find out the length by looking at public source code) 2. Providing a C implementation via the operator module (given the restriction to bytes values, and the assumption of caching for all relevant integers, would a C reimplementation really be buying us much additional security?) As far as restoring unicode support (even in a C implementation) goes, I actually don't like the idea. For the general unicode case, as suggested in the updated documentation for hexdigest(), I believe the better approach is to try to stay in the bytes domain as much as possible, and avoid having a Unicode-bytes conversion for the expected value anywhere in the comparison timing path. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Antoine Pitrou pit...@free.fr added the comment: 2. Providing a C implementation via the operator module (given the restriction to bytes values, and the assumption of caching for all relevant integers, would a C reimplementation really be buying us much additional security?) I like the fact that a C implementation can be audited much more easily. Who knows what kind of effects the Python implementation can trigger, if some optimizations get added in the future. As far as restoring unicode support (even in a C implementation) goes, I actually don't like the idea. For the general unicode case, as suggested in the updated documentation for hexdigest(), I believe the better approach is to try to stay in the bytes domain as much as possible, and avoid having a Unicode-bytes conversion for the expected value anywhere in the comparison timing path. The point of supporting unicode would precisely be to avoid a unicode-bytes conversion when unicode strings are received. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Christian Heimes li...@cheimes.de added the comment: Am 15.06.2012 14:21, schrieb Antoine Pitrou: I like the fact that a C implementation can be audited much more easily. Who knows what kind of effects the Python implementation can trigger, if some optimizations get added in the future. Secondly we can predict the function's timing on other implementations of Python. Jython or PyPy might have different settings for small int caching -- or non at all. The point of supporting unicode would precisely be to avoid a unicode-bytes conversion when unicode strings are received. A byte-wise comparison of the memory representation would work IFF both sides have the same type and unicode kind. Anything else could give away details of the content. Either: PyBytes_CheckExact(a) PyBytes_CheckExact(b) or PyUnicode_CheckExact(a) PyUnicode_CheckExact(b) PyUnicode_KIND(a) == PyUnicode_KIND(b) I'm not sure about CheckExact, just being paranoid. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15073] commands.getoutput() does not work on windows
R. David Murray rdmur...@bitdance.com added the comment: Hmm. Maybe issue 10197 should be reclassified as an enhancement... -- nosy: +r.david.murray resolution: wont fix - duplicate superseder: - subprocess.getoutput fails on win32 title: commands.getoutput() is broken - commands.getoutput() does not work on windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Antoine Pitrou pit...@free.fr added the comment: The point of supporting unicode would precisely be to avoid a unicode-bytes conversion when unicode strings are received. A byte-wise comparison of the memory representation would work IFF both sides have the same type and unicode kind. Anything else could give away details of the content. My proposal was to only allow them on ASCII strings. Any other unicode kind would raise an error (perhaps NotImplementedError). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15077] Regexp match goes into infinite loop
Serhiy Storchaka storch...@gmail.com added the comment: This is not infinite loop. This is O(2**len(prefix_before_first_quote)) computation. Measure times of matching for INSER(`id`..., INSERT(`id`..., INSERT (`id`..., INSERT I(`id`..., etc. Better use r'''(?:[^`';]+|'(?:''|[^'])*'|`(?:``|[^`])*`)+;''' regexp. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15078] Change os.sendfile so its arguments are stable
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +giampaolo.rodola, neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15073] commands.getoutput() does not work on windows
Pavel Fedin p.fe...@samsung.com added the comment: I see it's deprecated and dropped, but anyway, why not to fix it to work on Windows? From 10197 i see the fix is quite simple, and there is lots of legacy code i believe. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15074] Strange behaviour of python cmd module. (Ignores slash)
Peter Otten __pete...@web.de added the comment:
Not a python bug. You are ommitting an important detail of the stackoverflow
example in your code:
# we want to treat '/' as part of a word, so override the delimiters
readline.set_completer_delims(' \t\n;')
Please turn to the Python mailing list if you need more help.
--
nosy: +peter.otten
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15074
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Nick Coghlan ncogh...@gmail.com added the comment: (Ah, the dangers of using a real text editor for edit fields. This got rather long, but I think it's all still relevant) I'm persuaded that a C implementation is a good idea in the long run. However, I *don't* think we should rush the design of it. It doesn't seem right to me to be adding a new function to the operator module this close to feature freeze (assuming that's even the right place to add this functionality), so I'd like to close this issue on the basis of my last round of updates, and create a new one aimed at 3.4 to provide a lower level time independent bytes comparison primitive. I have a couple of major reasons for feeling this way: Firstly, the various Python web servers and frameworks have achieved a tolerable level of security through pure Python bytes comparisons that simply avoid short circuiting (sufficent to avoid them getting CVEs raised against them, anyway) Secondly, it seems to me that the proposed lower level feature may make more sense as a bytes method rather than as a function in the operator module. Consider the proposed properties for the lower level security primitive: 1. Handle comparison of bytes objects via C level indexing and xor operations I agree on the value of this part - it makes our implementation easy to audit, and explicitly puts the burden on other implementations to support this as a security primitive. Either approach (bytes method or operator function) would achieve this goal. 2. Only leak length information for one of the supplied arguments under timing analysis. Initially I was thinking a function based implementation of this would be confusing, as it would be quite hard to remember which parameter controlled the perceived length. However, I realised it doesn't actually matter - if controlled by the expected value, then the comparison time appears independent of the input length, and doesn't leak clear timing information on the expected length. If controlled by the input value, then it varies with the input length and still doesn't leak clear information regarding the length of the expected value. However, we can exploit the asymmetry of a method call signature to make it clear that in expected.compare(provided), the time taken for the comparison is dictated by the length of expected (or vice-versa - whichever way gets chosen, the asymmetry should help make it easier to remember). In either case, hmac.compare_digest would remain as a simpler argument order doesn't matter, but the expected length is assumed to be public API (which, given real world use cases, is actually a reasonable assumption). 3. Handles Unicode objects of the same kind via C level indexing and xor operations I'm still not seeing the point of this. To avoid timing attacks based on encoding your best bet is to do any encoding steps *before* calculating and comparing any signatures (that way the encoding duration is certain to be independent of any secrets involved in the signature verification). The reason the embedded unicode support was problematic was because both the supplied *and* the expected value were being converted to integers during the comparison, and a timing analysis could potentially exploit that to retrieve information about the expected value. The timing vulnerability comes from this sequence: 1. Receive Unicode message, with signature 2. In Unicode, derive expected signature from message 3. Encode expected signature -- Timing vulnerability here 4. Encode received signature 5. Compare the derived and expected signature The original implementation had this problem, because the repeated calls to ord() were roughly equivalent to encoding the string as UTF-32, only with even bigger timing variations (due to the integer caching behaviour) Compare that with the following sequence, which avoids the problem: 1. Receive Unicode message, with signature 2. Encode the received signature to bytes 3. Encode the message to bytes -- Cannot expose signature related secrets 4. Derive the expected signature from the encoded message 5. Compare the derived and expected signature Given that crypto primitives are designed to operate on byte sequences *anyway*, the latter approach is likely to be the only one that works regardless of Unicode support (or lack thereof). Really, I think the Unicode support in the initial version of the function was just a mistake, pure and simple - the use of ord() during the iteration is a 2.x backwards compatibility trick for 8-bit strings that isn't applicable in the 3.x standard library. You can see this in the equivalent code in the tornado web server, where the ord() based implementation is invoked to handle Python 2 byte strings, not Unicode text: https://github.com/facebook/tornado/blob/master/tornado/web.py#L2004 4. The operator module is about protocols, this is not a protocol Unlike the other operations in operator, this operation
[issue15078] Change os.sendfile so its arguments are stable
Serhiy Storchaka storch...@gmail.com added the comment: I believe, that instead of a integer flags will be better and more portable to use boolean parameters (diskio=True, wait=True, sync=False). All additional parameters should be keyword-only. os.sendfile(out, in, offset, nbytes, *, headers=None, trailers=None, diskio=True, wait=True, sync=False) -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15052] Outdated comments in build_ssl.py
Jeremy Kloth jeremy.kl...@gmail.com added the comment: I would suggest trying to build OpenSSL (build_ssl.py) *without* Perl installed. On Windows (7,64-bit at least) a dialog box pops up many times asking which program to use to run XXX.pl. This is using the externals from svn.python.org. -- nosy: +jeremy.kloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15019] String termination on Linux
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Jānis: Prints 11 This is not what I get on Linux: I see 11 Hithere:) because the console chooses to not print the \x00. The character is present in the output stream though. Did you really got a truncated output? How did you run the above script? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15019 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Joey Geralnik jgeral...@gmail.com added the comment: First off, I'm a complete noob looking at the python source code for the first time so forgive me if I've done something wrong. What if the length of the chunk is checked as well? The following code works fine: import sys while True: chunk = sys.stdin.read(1000) if not chunk: break # process if len(chunk) 1000: break Something similar could be done in the fileinput class. The patch I've attached checks if the number of bytes read from the file is less than the size of the buffer (which means that the file has ended). If so, the next time the file is to be read it skips to the next file instead. joey@j-Laptop:~/cpython$ ./python Python 3.3.0a3+ (default:befd56673c80+, Jun 15 2012, 17:14:12) [GCC 4.6.3] on linux Type help, copyright, credits or license for more information. import fileinput [73732 refs] lines = list(fileinput.input()) foo bar ^D [73774 refs] lines ['foo\n', 'bar\n'] [73780 refs] -- keywords: +patch nosy: +jgeralnik Added file: http://bugs.python.org/file26018/fileinput.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15066] make install error: ImportError: No module named _struct
suzhengchun suzhengc...@yahoo.com.cn added the comment:
Thank for your attention.
I try it:
suzc@linux-opensuse:22:02:51:Python-2.7.3$
PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 ./python -c 'import sys;
print(sys.path)'
['', '/WORK/suzc/installed/python/lib/python2.7',
'/WORK/suzc/installed/python/lib/python27.zip',
'/WORK/suzc/installed/python/lib/python2.7/plat-linux2',
'/WORK/suzc/installed/python/lib/python2.7/lib-tk',
'/WORK/suzc/installed/python/lib/python2.7/lib-old',
'/WORK/suzc/installed/python/lib/python2.7/lib-dynload',
'/WORK/suzc/.local/lib/python2.7/site-packages',
'/WORK/suzc/installed/python/lib/python2.7/site-packages']
suzc@linux-opensuse:22:03:03:Python-2.7.3$
PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 \
./python -c 'import _struct; print(_struct.__file__)'
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named _struct 1
suzc@linux-opensuse:22:03:23:Python-2.7.3$
And I read the log of make, it seems to be compiled OK:
-
ranlib libpython2.7.a
gcc -pthread -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.7.a -lpthread -ldl -lutil -lm
running build
running build_ext
building dbm using ndbm
building '_struct' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include
-I/WORK/suzc/software/Python-2.7.3/Include -I/WORK/suzc/software/Python-2.7.3
-c /WORK/suzc/software/Python-2.7.3/Modules/_struct.c -o
build/temp.linux-x86_64-2.7/WORK/suzc/software/Python-2.7.3/Modules/_struct.o
gcc -pthread -shared
build/temp.linux-x86_64-2.7/WORK/suzc/software/Python-2.7.3/Modules/_struct.o
-L/WORK/suzc/installed/python/lib64 -L/usr/local/lib -o
build/lib.linux-x86_64-2.7/_struct.so
building '_ctypes_test' extension
-
_struct.o and _struct.so are just there, I truely don't know what's wrong.
Newly to Python, I think python should not have such an installation problem.
I installed it(2.7.3) on RHEL5, works OK, but I want to install OpenSSL to it,
don't know how to do it, so I learn to install it on SUSE in my workplace while
RHEL5 is in another place.
RHEL5 has python 2.4.2, in my memory. SUSE12 has python 2.7.2.
Does system's python affect my installtion? But I think it shouldn't.
In fact, long before I downloaded a compressed package named
Python-2.7.3.tar.bz2, with this one, I can make make install, but I can't
run it, error is:
suzc@linux-opensuse:22:12:31:bin$ ./python2.7
Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Traceback (most recent call last):
File /WORK/suzc/installed/python/lib/python2.7/site.py, line 564, in
module
main()
File /WORK/suzc/installed/python/lib/python2.7/site.py, line 546, in main
known_paths = addusersitepackages(known_paths)
File /WORK/suzc/installed/python/lib/python2.7/site.py, line 279, in
adduser
sitepackages
user_site = getusersitepackages()
File /WORK/suzc/installed/python/lib/python2.7/site.py, line 254, in
getuser
sitepackages
user_base = getuserbase() # this will also set USER_BASE
File /WORK/suzc/installed/python/lib/python2.7/site.py, line 244, in
getuser
base
USER_BASE = get_config_var('userbase')
File /WORK/suzc/installed/python/lib/python2.7/sysconfig.py, line 521, in
ge
t_config_var
return get_config_vars().get(name)
File /WORK/suzc/installed/python/lib/python2.7/sysconfig.py, line 420, in
ge
t_config_vars
_init_posix(_CONFIG_VARS)
File /WORK/suzc/installed/python/lib/python2.7/sysconfig.py, line 288, in
_i
nit_posix
raise IOError(msg)
IOError: invalid Python installation: unable to open
/WORK/suzc/installed/python
/lib/python2.7/config/Makefile (No such file
or directory)
I'm crazy about this, I search it in google, no satisfatory answers. So I want
to download a new one 2.7.3, and install, but i just can not install it.
Thanks again.
--
___
Python tracker rep...@bugs.python.org
[issue15068] fileinput requires two EOF when reading stdin
Serhiy Storchaka storch...@gmail.com added the comment: The patch I've attached checks if the number of bytes read from the file is less than the size of the buffer (which means that the file has ended). From io.RawIOBase.read docs: Read up to n bytes from the object and return them. As a convenience, if n is unspecified or -1, readall() is called. Otherwise, only one system call is ever made. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If 0 bytes are returned, and n was not 0, this indicates end of file. This is not an arbitrary assumption. In particular, when reading from a terminal with line buffering (you can edit the line until you press Enter) on C level you read only a whole line (if line length is not greater than buffer length) and 0 bytes you will receive only by pressing ^D or ^Z at the beginning of the line. Same for pipes and sockets. On Python level there are many third-party implementations of file-like objects which rely on this behavior, you cannot rewrite all of them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Joey Geralnik jgeral...@gmail.com added the comment: But this is calling the readlines function, which continually reads from the file until more bytes have been read than the specified argument. From bz2.readlines: size can be specified to control the number of lines read: no further lines will be read once the total size of the lines read so far equals or exceeds size. Do other file-like objects interpret this parameter differently? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Joey Geralnik jgeral...@gmail.com added the comment: Forget other filelike objects. The FileInput class only works with actual files, so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
R. David Murray rdmur...@bitdance.com added the comment: fileinput should work (for some definition of work) for anything that can be opened by name using the open syscall on unix. That includes many more things than files. Named pipes are a particularly interesting example in this context. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
R. David Murray rdmur...@bitdance.com added the comment: So the real question is: does readlines block until the byte count is satisified? It might, but the docs for io.IOBase.readlines leave open the possibility that fewer lines will be read, and do not limit that to the EOF case. It's not clear, however, if that is because the non-EOF-short-read case is specifically being allowed for, or if the documenter just didn't consider that case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
R. David Murray rdmur...@bitdance.com added the comment: The _pyio.py version of readlines does read until the count is equaled or exceeded. This could, however, be an implementation detail and not part of the spec. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Antoine Pitrou pit...@free.fr added the comment: Le vendredi 15 juin 2012 à 14:41 +, Serhiy Storchaka a écrit : From io.RawIOBase.read docs: Read up to n bytes from the object and return them. As a convenience, if n is unspecified or -1, readall() is called. Otherwise, only one system call is ever made. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. But sys.stdin does not implement RawIOBase, it implements TextIOBase. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Serhiy Storchaka storch...@gmail.com added the comment: Forget other filelike objects. The FileInput class only works with actual files, No. sys.stdin can be reassigned before using FileInput. And FileInput has openhook parameter (for read compressed files or get files from Web, for example). so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong? qwert 'qwert\n' You type five characters qwert end press Enter. Python immediately receives these six characters, and returns a result of sys.stdin.readline(1000). Only six characters, and no one symbol more, because more characters you have not entered yet. I believe that for such questions will be more appropriate to use a mailing list (python-l...@python.org, or newsgroup gmane.comp.python.general on news://news.gmane.org), and not bugtracker. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Antoine Pitrou pit...@free.fr added the comment: so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong? qwert 'qwert\n' You type five characters qwert end press Enter. Python immediately receives these six characters, and returns a result of sys.stdin.readline(1000). Well, did you try readline() or readlines()? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15061] hmac.secure_compare() leaks information about length of strings
Antoine Pitrou pit...@free.fr added the comment: Secondly, it seems to me that the proposed lower level feature may make more sense as a bytes method rather than as a function in the operator module. If it's a function, though, it can compare all kinds of buffer-like objects (bytearrays, memoryviews, etc.). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14955] hmac.secure_compare() is not time-independent for unicode strings
Jon Oberheide j...@oberheide.org added the comment: Sounds good to me, Nick. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15064] multiprocessing should use more context manager
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Serhiy Storchaka storch...@gmail.com added the comment: But sys.stdin does not implement RawIOBase, it implements TextIOBase. sys.stdin.buffer.raw implements RawIOBase. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Serhiy Storchaka storch...@gmail.com added the comment: qwert 'qwert\n' Oh, it seems that the mail server again ate some lines of my examples. Well, did you try readline() or readlines()? Yes, it's my mistake, I used readline(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14904] test_unicode_repr_oflw (in test_bigmem) crashes
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 1c9635109079 by Antoine Pitrou in branch '2.7': Skip test_bigmem.test_unicode_repr_oflw, since it crashes (issue #14904). http://hg.python.org/cpython/rev/1c9635109079 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15079] pickle: Possibly misplaced test
New submission from Stefan M mstefa...@gmail.com: After issue7455 was fixed, a test was created to reflect the fix (Lib/test/pickletester.py @ AbstractPickleModuleTests.test_bad_input). The test makes sure that an UnpicklingError is raised whenever pickled data attempts to pop on an empty stack. Although tests on AbstractPickleModuleTests normally only run on the C implementation of pickle (on which UnpicklingError is thrown), they may also run on the Python implementation if the C implementation of pickle is not available (which throws IndexError). I'm not sure if it's still reasonable to assume that it's possible for the C implementation of pickle not to exist (the python module does), as I've discovered this by forcefully disabling the C implementation. pickle.Unpickler(io.BytesIO(b'0')).load() _pickle.UnpicklingError: unpickling stack underflow pickle._Unpickler(io.BytesIO(b'0')).load() IndexError: list assignment index out of range The current fix involves adding IndexError to the list of exceptions that may be raised and moving the testcase to AbstractPickleTests (where the tests are ran against both the C and Python impl). As I'm working on improving pickle in protocol v4, it might be worth considering adding more consistency to the exceptions that are being raised by the Python unpickler. -- components: Tests files: pickletester.py.patch keywords: patch messages: 162919 nosy: alexandre.vassalotti, collinwinter, mstefanro priority: normal severity: normal status: open title: pickle: Possibly misplaced test type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26019/pickletester.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15068] fileinput requires two EOF when reading stdin
Antoine Pitrou pit...@free.fr added the comment: Oh, it seems that the mail server again ate some lines of my examples. This is a bug in the e-mail gateway. You can lobby for a fix at http://psf.upfronthosting.co.za/roundup/meta/issue264 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15079] pickle: Possibly misplaced test
R. David Murray rdmur...@bitdance.com added the comment: It would be best to have the pickle tests always run against both the C and python code. We do this for other modules that have C versions of some or all of the Python code. And yes, making the two consistent is also good. Since pickle is generally not used without the C code, making the Python consistent with the C would seem to be a low-impact change. -- nosy: +r.david.murray versions: +Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14933] Misleading documentation about weakrefs
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 69177ff1a643 by Antoine Pitrou in branch '3.2': Issue #14933: fix misleading doc about weakref support in extension types. http://hg.python.org/cpython/rev/69177ff1a643 New changeset b17c8005e08a by Antoine Pitrou in branch 'default': Issue #14933: fix misleading doc about weakref support in extension types. http://hg.python.org/cpython/rev/b17c8005e08a New changeset 0ac1f90954dc by Antoine Pitrou in branch '2.7': Issue #14933: fix misleading doc about weakref support in extension types. http://hg.python.org/cpython/rev/0ac1f90954dc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14933] Misleading documentation about weakrefs
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14059] Implement multiprocessing.Barrier
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 2d2f206d040e by Richard Oudkerk in branch 'default': Issue #14059: Implement multiprocessing.Barrier http://hg.python.org/cpython/rev/2d2f206d040e -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15026] Faster UTF-16 encoding
Antoine Pitrou pit...@free.fr added the comment: Serhiy, the tests crash here in debug mode: $ ./python -m test -v test_unicode == CPython 3.3.0a4+ (default:b17c8005e08a+, Jun 15 2012, 19:28:56) [GCC 4.5.2] == Linux-2.6.38.8-desktop-10.mga-x86_64-with-mandrake-1-Official little-endian == /home/antoine/cpython/default/build/test_python_2567 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_unicode test_formatter_field_name_split (test.test_unicode.StringModuleTest) ... ok test_formatter_parser (test.test_unicode.StringModuleTest) ... ok test___contains__ (test.test_unicode.UnicodeTest) ... ok test_additional_rsplit (test.test_unicode.UnicodeTest) ... ok test_additional_split (test.test_unicode.UnicodeTest) ... ok test_ascii (test.test_unicode.UnicodeTest) ... ok test_aswidechar (test.test_unicode.UnicodeTest) ... ok test_aswidecharstring (test.test_unicode.UnicodeTest) ... ok test_bug1001011 (test.test_unicode.UnicodeTest) ... ok test_bytes_comparison (test.test_unicode.UnicodeTest) ... ok test_capitalize (test.test_unicode.UnicodeTest) ... ok test_casefold (test.test_unicode.UnicodeTest) ... ok test_center (test.test_unicode.UnicodeTest) ... ok test_codecs (test.test_unicode.UnicodeTest) ... python: Objects/unicodeobject.c:5401: _PyUnicode_EncodeUTF16: Assertion `(Py_uintptr_t)(PyObject*)(v))-ob_type))-tp_flags ((1L27))) != 0)) ? (void) (0) : __assert_fail (((PyObject*)(v))-ob_type))-tp_flags ((1L27))) != 0), Objects/unicodeobject.c, 5401, __PRETTY_FUNCTION__)), (((PyBytesObject *)(v))-ob_sval)) 1 == 0' failed. Fatal Python error: Aborted Current thread 0x7faa4980e700: File /home/antoine/cpython/default/Lib/test/test_unicode.py, line 1443 in test_codecs File /home/antoine/cpython/default/Lib/unittest/case.py, line 385 in _executeTestPart File /home/antoine/cpython/default/Lib/unittest/case.py, line 440 in run File /home/antoine/cpython/default/Lib/unittest/case.py, line 492 in __call__ File /home/antoine/cpython/default/Lib/unittest/suite.py, line 105 in run File /home/antoine/cpython/default/Lib/unittest/suite.py, line 67 in __call__ File /home/antoine/cpython/default/Lib/unittest/suite.py, line 105 in run File /home/antoine/cpython/default/Lib/unittest/suite.py, line 67 in __call__ File /home/antoine/cpython/default/Lib/unittest/suite.py, line 105 in run File /home/antoine/cpython/default/Lib/unittest/suite.py, line 67 in __call__ File /home/antoine/cpython/default/Lib/unittest/runner.py, line 168 in run File /home/antoine/cpython/default/Lib/test/support.py, line 1383 in _run_suite File /home/antoine/cpython/default/Lib/test/support.py, line 1417 in run_unittest File /home/antoine/cpython/default/Lib/test/test_unicode.py, line 1954 in test_main File /home/antoine/cpython/default/Lib/test/regrtest.py, line 1237 in runtest_inner File /home/antoine/cpython/default/Lib/test/regrtest.py, line 918 in runtest File /home/antoine/cpython/default/Lib/test/regrtest.py, line 710 in main File /home/antoine/cpython/default/Lib/test/__main__.py, line 13 in module File /home/antoine/cpython/default/Lib/runpy.py, line 75 in _run_code File /home/antoine/cpython/default/Lib/runpy.py, line 162 in _run_module_as_main Abandon -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14874] Faster charmap decoding
Changes by Antoine Pitrou pit...@free.fr: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15075] XincludeTest failure in test_xml_etree
Eli Bendersky eli...@gmail.com added the comment: Here is a patch that solves the current problem. A longer term solution would be to have a cleaner test plan for ET in general, without monkey-patching at all, and without state that causes test-order dependencies. -- keywords: +patch Added file: http://bugs.python.org/file26020/issue15075.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15036] mailbox.mbox fails to pop two items in a row, flushing in between
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 0add70dd3c43 by Petri Lehtinen in branch '2.7': #15036: Make a repeated changes and flushes work with single-file mailboxes http://hg.python.org/cpython/rev/0add70dd3c43 New changeset 714b8f91f3d4 by Petri Lehtinen in branch '3.2': #15036: Make a repeated changes and flushes work with single-file mailboxes http://hg.python.org/cpython/rev/714b8f91f3d4 New changeset 87d119117560 by Petri Lehtinen in branch 'default': #15036: Make a repeated changes and flushes work with single-file mailboxes http://hg.python.org/cpython/rev/87d119117560 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15008] PEP 362 Signature Objects reference implementation
Yury Selivanov yseliva...@gmail.com added the comment: Attaching the new version of the patch. Summary: 1. 'is_*' family was replaced with 'Parameter.kind' 2. 'signature()' function was updated to check for '__wrapped__' attribute in all callables 3. 'is_implemented' - 'implemented' 4. Added support for POSITIONAL_ONLY parameters (in 'bind()') -- Added file: http://bugs.python.org/file26021/pep362.3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15036] mailbox.mbox fails to pop two items in a row, flushing in between
Changes by Petri Lehtinen pe...@digip.org: -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15036] mailbox.mbox fails to pop two items in a row, flushing in between
R. David Murray rdmur...@bitdance.com added the comment: The news item isn't completely clear. It sounds like the mailbox is now automatically being flushed between pops, but what you really fixed is popping if the *application* does a flush between them, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15074] Strange behaviour of python cmd module. (Ignores slash)
Changes by Ned Deily n...@acm.org: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
