[issue20994] Disable TLS Compression

2014-03-20 Thread Alex Stapleton

Alex Stapleton added the comment:

CRIME is not universally applicable to all TLS connections and it requires some 
cooperation from the application to work. In fact for a Python TLS client it 
seems quite unlikely for an application to be vulnerable. The attack in the 
paper leverages an insecure website to inject JavaScript to issue crafted 
requests to a secure one. i.e. It requires both compression and some degree of 
remote code execution to work. Perhaps there are ways to extend the attack to 
apply to more common Python TLS client usage though?

Also some users will absolutely want to manually re-enable compression, please 
don't disable it entirely.

--
nosy: +Alex.Stapleton

___
Python tracker 
<http://bugs.python.org/issue20994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8397] BZ2File doesn't protect against mixed iterator and read usage

2010-04-14 Thread Alex Stapleton

New submission from Alex Stapleton :

Normal files throw exceptions if you mix methods.

>>> f = open("words")
>>> for l in f:
... break
... 
>>> f.tell()
8192L
>>> f.readline()
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Mixing iteration and read methods would lose data



BZ2Files silently do the wrong thing. (Output is a coincidence. Honest!)

>>> import bz2
>>> f = bz2.BZ2File("words.bz2")
>>> for l in f:
... break
... 
>>> f.tell()
8192L
>>> f.readline()
'lose\n'


Expected behaviour is for it to throw a ValueError like normal file objects.

--
components: None
messages: 103126
nosy: Alex.Stapleton
severity: normal
status: open
title: BZ2File doesn't protect against mixed iterator and read usage
versions: Python 2.5, Python 2.6

___
Python tracker 
<http://bugs.python.org/issue8397>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4610] Unicode case mappings are incorrect

2008-12-20 Thread Alex Stapleton

Alex Stapleton  added the comment:

I am trying to get a PEP together for this. Does anyone have any thoughts 
on how to handle comparison between unicode strings in a locale aware 
situation?

Should __lt__ and __gt__ be specified as ignoring locale? In which case do 
we need to add a new method for doing locale aware comparisons?

Should locale be a property of the string, an argument passed to 
upper/lower/isupper/islower/swapcase/capitalize/sort or global state 
(locale module...)?

Should doing a locale aware comparison of two strings with different 
locales throw an exception?

Should locales be represented as objects or just a string like "en_GB"?

___
Python tracker 
<http://bugs.python.org/issue4610>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4610] Unicode case mappings are incorrect

2008-12-10 Thread Alex Stapleton

Alex Stapleton <[EMAIL PROTECTED]> added the comment:

I agree with loewis that ICU is probably the best way to get this 
functionality into Python.

lemburg, yes it seems like extending those methods would be required at 
the very least. We would probably also need to support ICUs collators as 
well I think.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4610>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4610] Unicode case mappings are incorrect

2008-12-09 Thread Alex Stapleton

New submission from Alex Stapleton <[EMAIL PROTECTED]>:

Following a discussion on reddit it seems that the unicode case
conversion algorithms are not being followed.

$ python3.0
Python 3.0rc1 (r30rc1:66499, Oct 10 2008, 02:33:36) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x='ß'
>>> print(x, x.upper())
ß ß

This conversion is correct as defined in UnicodeData.txt however
http://unicode.org/Public/UNIDATA/SpecialCasing.txt defines a more
complete set of case conversions.

According to this file "ß".upper() should be "SS". Presumably Python
simply isn't using this file to create it's mapping database.

--
components: Unicode
messages: 77417
nosy: alexs
severity: normal
status: open
title: Unicode case mappings are incorrect
type: behavior
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4610>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com