Antoine Pitrou writes:
That's unsubstantiated.
Sure. If I had a CVE, I would have posted it.
Give an example of how sorted URLs compromise security.
That's not how you think about security; the right question about
sorted URLs is how do you know that they *don't* compromise
security? We
Joao S. O. Bueno writes:
Ageeded that any way one thinks about it is far too strong a claim -
but I still hold to the point. Maybe most ways one thinks about it
:-) .
100% agreement now.wink/
___
Python-Dev mailing list
Python-Dev@python.org
On Sun, 19 Aug 2012 20:55:31 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Antoine Pitrou writes:
That's unsubstantiated.
Sure. If I had a CVE, I would have posted it.
Ok, so you have no evidence.
Regards
Antoine.
___
Python-Dev
On Sat, Aug 18, 2012 at 1:55 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On 8/18/2012 11:47 AM, MRAB wrote:
I vote -0. The issue can also be addressed with a small and simple
helper function that wraps urlparse and compares the query parameter. Or
you cann urlencode() with
Guido van Rossum wrote:
I wonder if it wouldn't make sense to change urlencode() to generate
URLs that don't depend on the hash order, for all versions of Python
that support PYTHONHASHSEED? It seems a one-line fix:
query = query.items()
with this:
query = sorted(query.items())
On Sat, 18 Aug 2012 14:23:13 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Joao S. O. Bueno writes:
I don't think this behavior is only desirable to unit tests: having
URL's been formed in predictable way a good thing in any way one
thinks about it.
Especially if you're a
On 18 August 2012 02:23, Stephen J. Turnbull step...@xemacs.org wrote:
Joao S. O. Bueno writes:
I don't think this behavior is only desirable to unit tests: having
URL's been formed in predictable way a good thing in any way one
thinks about it.
Especially if you're a hacker. One
Am 17.08.2012 21:27, schrieb Guido van Rossum:
I wonder if it wouldn't make sense to change urlencode() to generate
URLs that don't depend on the hash order, for all versions of Python
that support PYTHONHASHSEED? It seems a one-line fix:
query = query.items()
with this:
On Sat, Aug 18, 2012 at 6:28 AM, Christian Heimes li...@cheimes.de wrote:
Am 17.08.2012 21:27, schrieb Guido van Rossum:
I wonder if it wouldn't make sense to change urlencode() to generate
URLs that don't depend on the hash order, for all versions of Python
that support PYTHONHASHSEED? It
On 18/08/2012 18:34, Guido van Rossum wrote:
On Sat, Aug 18, 2012 at 6:28 AM, Christian Heimes li...@cheimes.de wrote:
Am 17.08.2012 21:27, schrieb Guido van Rossum:
I wonder if it wouldn't make sense to change urlencode() to generate
URLs that don't depend on the hash order, for all versions
On Saturday, August 18, 2012, MRAB wrote:
On 18/08/2012 18:34, Guido van Rossum wrote:
On Sat, Aug 18, 2012 at 6:28 AM, Christian Heimes li...@cheimes.de
wrote:
Am 17.08.2012 21:27, schrieb Guido van Rossum:
I wonder if it wouldn't make sense to change urlencode() to generate
URLs that
On 8/18/2012 11:47 AM, MRAB wrote:
I vote -0. The issue can also be addressed with a small and simple
helper function that wraps urlparse and compares the query parameter. Or
you cann urlencode() with `sorted(qs.items)` instead of `qs` in the
application.
Hm. That's actually a good point.
I just fixed a unittest for some code used at Google that was
comparing a url generated by urllib.encode() to a fixed string. The
problem was caused by turning on PYTHONHASHSEED=1. Because of this,
the code under test would generate a textually different URL each time
the test was run, but the
Only if it is not an OrderedDict
query = sorted(query.items())
This would not prevent breakage of unit tests, but it would make a
much simpler fix possible: simply sort the parameters in the URL.
___
Python-Dev mailing list
On 17.08.2012 21:27, Guido van Rossum wrote:
query = sorted(query.items())
This would not prevent breakage of unit tests, but it would make a
much simpler fix possible: simply sort the parameters in the URL.
Thoughts?
Sounds good. For best backwards compatibility, I'd restrict the
Thanks, I filed http://bugs.python.org/issue15719 to track this.
On Fri, Aug 17, 2012 at 12:50 PM, Martin v. Löwis mar...@v.loewis.de wrote:
On 17.08.2012 21:27, Guido van Rossum wrote:
query = sorted(query.items())
This would not prevent breakage of unit tests, but it would make a
On Sat, Aug 18, 2012 at 5:27 AM, Guido van Rossum gu...@python.org wrote:
I just fixed a unittest for some code used at Google that was
comparing a url generated by urllib.encode() to a fixed string. The
problem was caused by turning on PYTHONHASHSEED=1. Because of this,
the code under test
On 17 August 2012 18:52, Chris Angelico ros...@gmail.com wrote:
On Sat, Aug 18, 2012 at 5:27 AM, Guido van Rossum gu...@python.org wrote:
I just fixed a unittest for some code used at Google that was
comparing a url generated by urllib.encode() to a fixed string. The
problem was caused by
Joao S. O. Bueno writes:
I don't think this behavior is only desirable to unit tests: having
URL's been formed in predictable way a good thing in any way one
thinks about it.
Especially if you're a hacker. One more thing you may be able to use
against careless sites that don't expect the
19 matches
Mail list logo
