[issue14621] Hash function is not randomized properly
René added the comment:
Christian Heimes: It has always been trivial to artificially generate
collisions for fast hashes designed for hash tables, like MurmurHash. I
wouldn't call Murmurhash3 "busted" because of that, as this was never a design
goal. It is a known propriety of this type of hash: you do that basically
running them backwards. You can't even call that cryptanalysis.
Of course, you need the seed to search those collisions, but from this thread
it seems very difficult, if not impossible, not to leak the random seed to the
attacker.
I see the various collision counting alternatives proposed as the less
intrusive and definitive solution for this problem. It also has the benefit
that it can work for any type of key. Some pseudo code:
hash as always, with a fast hash.
if reprobes > initial_threshold:
if the table has only one key type AND it has a robust comparison method:
store the collisions in a O(log n) worst case structure (tree).
elif the object has a secondary slow secure hash:
try searching/inserting the key again with the new secure hash.
It works like a double hashing reprobing hash table.
elif collisions > max_threshold:
raise Exception("Under attack or the object is using a crappy hash,
with no fallback.")
The first option, the O(log n) structure, can be ignored as unnecessary
complication (even though there is already a path implementing that), but I
suspect it may be faster than a secure hash. If not, then there is really no
point in this option, except if the secure hash proves to be not so secure.
--
nosy: +ReneSac
___
Python tracker
<http://bugs.python.org/issue14621>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
René added the comment: Serhiy Storchaka: I said a O(log n) data structure, so I was referring to balanced trees, like AVL, RBT or B+-tree. They are not vulnerable to sorted data. The downside is that they need the keys to provide robust comparison methods (like, if z < y < x, then z < x). Christian Heimes: Right, the seed indeed doesn't provides protection... But the collision counting is compatible with your two suggestions, and solves the problem. The only difference is that you don't get the performance hit if not under attack. -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
René added the comment: Serhiy Storchaka: Yes, but it is still O(log n) worst case. Even in the worst case rebalancing, you only need to walk up/down rotating/spliting every node in your path. As the tree height is guaranteed to be x * log n (x from 1 to 2, depending on the algorithm), the rebalancing operation is aways limited by O(log n). -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by René Liebscher : -- nosy: +r.liebscher ___ Python tracker <http://bugs.python.org/issue2001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
René Liebscher added the comment: What about http://bugs.python.org/issue2001#msg114326 ? -- ___ Python tracker <http://bugs.python.org/issue2001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Changes by René Schümann : -- nosy: +WhiteTiger ___ Python tracker <http://bugs.python.org/issue1006238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by René Schümann : -- nosy: +WhiteTiger ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3754] cross-compilation support for python build
Changes by René Schümann : -- nosy: +WhiteTiger ___ Python tracker <http://bugs.python.org/issue3754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1857] subprocess.Popen.poll/__del__ API breakage
New submission from René Stadler: The commit to r45234 has added an internally used keyword attribute named _deadstate to subprocess.Popen.poll, which is called by the __del__ method of this class. If you derived your own class from subprocess.Popen that overrides .poll() without taking kwargs, the __del__ method will trigger a TypeError about the unexpected keyword argument. Attached is a very simple test program that triggers the problem. It runs just fine with Python 2.4 however. -- components: Library (Lib) files: subprocessapi.py messages: 60024 nosy: rene.st severity: major status: open title: subprocess.Popen.poll/__del__ API breakage versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9190/subprocessapi.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1857> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1857] subprocess.Popen.poll/__del__ API breakage
René Stadler added the comment: Yes, it works. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1857> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue902061] pydoc insists upon producing file: URLs
René Liebscher <[EMAIL PROTECTED]> added the comment: I would like to see this change introducing a method of class HTMLDoc. It has already some such methods as: def namelink(self, name, *dicts): def classlink(self, object, modname): def modulelink(self, object): def modpkglink(self, data): So it would be logically to make it a method def filelink(self,url,path): """Make a link to source file.""" return '%s' % (url, path) and changing the creating of the filelink to ... filelink = self.filelink(url, path) except TypeError: filelink = '(built-in)' ... This way one can easily subclass HTMLDoc for own purposes and define a own filelink method. -- nosy: +r.liebscher ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue902061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30752] Basic subtraction is wrong ( 1.83 - 1.52 == 0.31000000000000005)
New submission from René Podlogar: My Python-Installations Python 2.7.12, Python 3.4.5 @linux64 and the CLI on the python.org-Website (interactive shell) affected: Python 3.6.0 (default, Jan 13 2017, 00:00:00) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 1.83 - 1.52 0.31005 >>> Expected= 0.31 Verified in irc-channel #python.de -- messages: 296817 nosy: René Podlogar priority: normal severity: normal status: open title: Basic subtraction is wrong ( 1.83 - 1.52 == 0.31005) versions: Python 2.7, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20793] locale.setlocale()
New submission from René Fleschenberg:
locale.setlocale() does not work if you pass it a ``unicode`` object instead of
a ``str`` (locale.py, line 576):
``if locale and type(locale) is not type(""):``
Maybe it would be better to do a check like this?
``if locale and not isinstance(locale, basestring):``
In particular, this can bite you if you use the ``unicode_literals`` future
import, displaying a not-so-helpful error message ("ValueError: too many values
to unpack" in _build_localename).
--
messages: 212350
nosy: rene
priority: normal
severity: normal
status: open
title: locale.setlocale()
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue20793>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20793] locale.setlocale()
René Fleschenberg added the comment: I see. Thanks for the information. -- ___ Python tracker <http://bugs.python.org/issue20793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5415] uuid module generates incorrect values for uuid3 (and possibly uuid5)
New submission from René Puls :
I am trying to recreate the sample output from appendix B of RFC 4122.
http://www.ietf.org/rfc/rfc4122.txt
In that document, a version 3 UUID is created using the DNS namespace
(6ba7b810-9dad-11d1-80b4-00c04fd430c8, same as uuid.NAMESPACE_DNS in
Python) and the name 'www.widgets.com'.
The result according to the RFC should be:
e902893a-9d22-3c7e-a7b8-d6e313b71d9f
Here is the output from the Python uuid module:
>>> import uuid
>>> uuid.NAMESPACE_DNS
UUID('6ba7b810-9dad-11d1-80b4-00c04fd430c8')
>>> uuid.uuid3(uuid.NAMESPACE_DNS, 'www.widgets.com')
UUID('3d813cbb-47fb-32ba-91df-831e1593ac29')
I couldn't find any test cases for the Python module. Did I use it
incorrectly, or is the calculation really off?
--
components: Library (Lib)
messages: 83118
nosy: pwr
severity: normal
status: open
title: uuid module generates incorrect values for uuid3 (and possibly uuid5)
type: behavior
versions: Python 2.6, Python 3.0
___
Python tracker
<http://bugs.python.org/issue5415>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
René Schümann added the comment: Roumen thanks for this work, but will you upload a new version? Just because i can't get it to work, i can't even patch it^^ Maybe it's the SVN Client i use (Tortoise SVN) or that i don't know how to apply this patch :D It would be nice when you help me Kind regards -- nosy: +WhiteTiger ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
René Schümann added the comment: @LRN what program did u used to create the patch? And what to apply it? Just because i can't get Tortoise to apply the patch (An unknown line type was found in line 678 !) and MSYS's patch also does not work. -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30516] Documentation for datetime substract operation incorrect?
New submission from René Hernández Remedios: In the documentation for the supported arithmetic operations for a datetime object, there is the following note, among other: datetime2 = datetime1 - timedelta Comment: Computes the datetime2 such that datetime2 + timedelta == datetime1. As for addition, the result has the same tzinfo attribute as the input datetime, and no time zone adjustments are done even if the input is aware. This isn’t quite equivalent to datetime1 + (-timedelta), because -timedelta in isolation can overflow in cases where datetime1 - timedelta does not. While reading the source code for __sub__ operation I found in the first few lines: Line 1885: def __sub__(self, other): "Subtract two datetimes, or a datetime and a timedelta." if not isinstance(other, datetime): if isinstance(other, timedelta): return self + -other return NotImplemented Is the documentation in contradiction with the actual implementation? -- messages: 294787 nosy: René Hernández Remedios priority: normal severity: normal status: open title: Documentation for datetime substract operation incorrect? versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21972] Bugs in the lexer and parser documentation
New submission from François-René Rideau: The lexer documentation says that the u prefix works on strings since 3.3, but doesn't explain what or how, which is all the more problematic since it explicitly mentions difference from the behavior documented in Python 2. It also doesn't specify the ELLIPSIS token or the <> future token mentioned in the grammar (that should probably be removed, for PEP 401 is a joke — unless that's intentional, in which case a smiley might be useful). https://docs.python.org/3.5/reference/lexical_analysis.html -- assignee: docs@python components: Documentation messages: 222906 nosy: François-René.Rideau, docs@python priority: normal severity: normal status: open title: Bugs in the lexer and parser documentation type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue21972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21972] Bugs in the lexer and parser documentation
François-René Rideau added the comment: Actually, my reading was buggy, and the "u" part is well-documented enough. Apologies for this part of the bug report. The lexer documentation is still missing the ellipsis, though Other bug I found in the lexer documentation: missing @= And the parser documentation of <> is probably a bug. -- ___ Python tracker <http://bugs.python.org/issue21972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22144] ellipsis needs better display in lexer documentation
New submission from François-René Rideau: As a followup to http://bugs.python.org/issue21972 The ellipsis (three dots) should be displayed in the box on top of section 2.6 of the reference manual, and not just in the text below: https://docs.python.org/3.5/reference/lexical_analysis.html -- messages: 224854 nosy: François-René.Rideau priority: normal severity: normal status: open title: ellipsis needs better display in lexer documentation versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue22144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22145] <> in parser spec but not lexer spec
New submission from François-René Rideau: As another follow up to http://bugs.python.org/issue21972 <> is mentioned in the parser spec: https://docs.python.org/3.5/reference/grammar.html But not in the lexer spec: https://docs.python.org/3.5/reference/lexical_analysis.html Either is a mistake. I suggested in issue 21972 that the former was the bug, because it referred to a joke PEP and because <> doesn't actually work as a comparator in Python 3.4. The response by loewis was that the parser documentation was correct — well then the lexer documentation is incorrect. -- assignee: docs@python components: Documentation messages: 224856 nosy: François-René.Rideau, docs@python, loewis priority: normal severity: normal status: open title: <> in parser spec but not lexer spec type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue22145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27121] imghdr does not support jpg files with Lavc bytes
New submission from René Løwe Jacobsen: Some jpegs might have Lavc instead of JFIF or Exif. I have added a picture for you to test with. -- files: 5ZK0umWbRmsQwGkUb4LhIV6L9YnInn6t_thumb.jpg messages: 266327 nosy: René Løwe Jacobsen priority: normal severity: normal status: open title: imghdr does not support jpg files with Lavc bytes versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42987/5ZK0umWbRmsQwGkUb4LhIV6L9YnInn6t_thumb.jpg ___ Python tracker <http://bugs.python.org/issue27121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
crash in Py_EnterRecursiveCall
Hello,
I have embedded Python into and extended it with functionality from a
graphical tool I use. One of the things it allows me to do is to
export Python objects to a simple scripting language ("ascanf"), and
call them as if they were native functions.
I have the following situation in which I get a systematic
segmentation violation in Py_EnterRecursiveCall(), in Python 2.3
(Apple's Mac OS X 10.4 system version), 2.4 2.5 and 2.6 (OS X) and on
Cygwin with 2.5 and 2.6
I enter an interactive Python 'console' from within my application,
either the one from the interact package, or the IPython shell. My
application has a callback defined for the readline routines that
calls the graphical event handler, allowing for instance
refresh/redraws to continue while working in the Python console. The
crash occurs when during such events handled through the readline
callback, I call an exported Python object. This does not appear to be
related to recursion per se, but rather to "calling a python
interpreter behind the back of the currently active
console/interpreter".
To be clearer, suppose I have some Python code
def Py_travDistCalc(a,b,c):
...
return x
ascanf.ExportVariable("travDistCalc", Py_travDistCalc )
I can then issue a call
1) travDistCalc[a,b,c] from an ascanf script.
2) ascanf.Eval( 'travDistCalc[a,b,c]' ) from the Python console
Call 1) provokes a crash in Py_EnterRecursiveCall() when invoked
through the readline callback when the Python console is open, but
call 2) succeeds normally.
My workaround is to keep track of the readline callback recursion
level, and compare the current level with the level recorded when
entering a Python console before doing the PyObject_CallObject()
required in call 1) and 2) above.
I'm not sure if this is a bug in Python. It is the sort of crash
situation I'd try to avoid, though.
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41030] Provide toList() method on iterators (`list()` is a flow killer in REPL)
New submission from Julien Edmond René Harbulot : I work with python in the REPL or jupyter notebooks for my data science work and often find myself needing to explore data structures or directories on disk. So I'll access these data structure in a linear "go-forward" fashion using the dot, for instance: ``` root_directory = pathlib.Path(...) root_directory.iterdir()[0].iterdir() ``` Which of course doesn't work because iterdir() provides an iterator instead of a list (I understand this is good for performance, but how annoying for interactive sessions!) The problem with the current API is that: 1. I have to go back to my code and edit in several places to convert the iterators to lists. With the currrent way (i.e. `list( ... )`) I have to edit before the iterator to add `list(` and then after to add `)`. When my one-liners become complex, this is very tedious because I have to perform extensive search to find where to insert the `list(` part. Having a method `.toList()` would allow to edit the expression in a *single* place instead, and is also much easier to read in my opinion: ``` root_directory.iterdir().toList()[0].iterdir().toList() ``` instead of: ``` list(list(root_directory.iterdir())[0].iterdir()) ``` 2. I want to think about my work, the business task at hand. Not about the particularities of python iterators. Having to specify `list(` first, forces me to think about the language. This gets in my way. The possiblity to use `.toList()` at the end of an expression allows the conversion to happen as an afterthought. In particular in REPL or notebooks where I'll often write: ``` directory.iterdir() ``` And the repl will display ``` ``` How easy would it be if I could just *append* to my code instead of surgically edit before and after. -- components: Demos and Tools messages: 371852 nosy: Julien Edmond René Harbulot priority: normal severity: normal status: open title: Provide toList() method on iterators (`list()` is a flow killer in REPL) type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41030] Provide toList() method on iterators (`list()` is a flow killer in REPL)
Julien Edmond René Harbulot added the comment: Consider how easy in the REPL it is to hit `up arrow` and then append code to the previously entered command, compared to having to move the cursor back in the command to edit it somewhere in the middle. Simulated REPL session: ``` dir.iterdir() > .toList() > [Path(...), Path(...)] ``` -- ___ Python tracker <https://bugs.python.org/issue41030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
