[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

2021-05-05 Thread Florian Apolloner

Florian Apolloner  added the comment:

Thank you for the kind words Michał. We (Django) are exactly in the position 
that you describe. Our validation, at least for now has to stay strict, exactly 
to prevent fallout further down the road (see 
https://github.com/django/django/pull/14349#pullrequestreview-652022529 for 
details).

Sure, we might have been a bit naive when relying on urllib.parse for parts of 
our validation routines, but this is why we have tests for this behavior. We 
can easily work around this fix and will issue a release shortly to prevent 
security issues for users on newer Python versions. But no matter how the 
Python code ends up in the long run, our validator (at least this specific 
class) cannot simply accept new URLs because a spec changed. We owe it to our 
users to keep in mind that relaxing the validation can cause other issues down 
the road.

--
nosy: +apollo13

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



[issue25110] Documentation sometimes still links to py3.4

2015-09-14 Thread Florian Apolloner

New submission from Florian Apolloner:

Compare those two URLs:
https://docs.python.org/3/whatsnew/
https://docs.python.org/3/

The first one shows version 3.4, whereas the later shows version 3.5.

--
messages: 250667
nosy: Florian.Apolloner
priority: normal
severity: normal
status: open
title: Documentation sometimes still links to py3.4

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



[issue25110] Documentation sometimes still links to py3.4

2015-09-14 Thread Florian Apolloner

Changes by Florian Apolloner <f.apollo...@gmail.com>:


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.5

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



[issue23882] unittest discovery and namespaced packages

2015-04-07 Thread Florian Apolloner

New submission from Florian Apolloner:

Unittest discovery does not seem to work if the tests package is  a namespace 
package. The attached file should have all details to reproduce, as soon as I 
readd an __init__.py everything works fine. 

Test was done using python3.4.2 and 3.4.3

--
files: console_log.txt
messages: 240205
nosy: Florian.Apolloner
priority: normal
severity: normal
status: open
title: unittest discovery and namespaced packages
versions: Python 3.4
Added file: http://bugs.python.org/file38857/console_log.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23882
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode

2014-01-06 Thread Florian Apolloner

Changes by Florian Apolloner flor...@apolloner.eu:


--
nosy: +apollo13

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20138
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20089] email.message_from_string no longer working in Python 3.4

2013-12-28 Thread Florian Apolloner

New submission from Florian Apolloner:

Given this email:
---
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: =?utf-8?q?Ch=C3=A8re_maman?=
From: f...@example.com
To: t...@example.com
Date: Sat, 28 Dec 2013 13:08:07 -
Message-ID: 20131228130807.3669.79195@localhost

Je t'aime très fort
---

I get this traceback:
---
  File /home/florian/sources/cpython/Lib/email/__init__.py, line 40, in 
message_from_string
return Parser(*args, **kws).parsestr(s)
  File /home/florian/sources/cpython/Lib/email/parser.py, line 70, in parsestr
return self.parse(StringIO(text), headersonly=headersonly)
  File /home/florian/sources/cpython/Lib/email/parser.py, line 60, in parse
return feedparser.close()
  File /home/florian/sources/cpython/Lib/email/feedparser.py, line 170, in 
close
self._call_parse()
  File /home/florian/sources/cpython/Lib/email/feedparser.py, line 163, in 
_call_parse
self._parse()
  File /home/florian/sources/cpython/Lib/email/feedparser.py, line 449, in 
_parsegen
self._cur.set_payload(EMPTYSTRING.join(lines))
  File /home/florian/sources/cpython/Lib/email/message.py, line 311, in 
set_payload
 payload) from None
TypeError: charset argument must be specified when non-ASCII characters are 
used in the payload
---

This is new in 3.4 since that's the first version which requires set_payload to 
provide a charset argument, imo message_from_string should figure that out from 
the message.

--
messages: 207028
nosy: apollo13
priority: normal
severity: normal
status: open
title: email.message_from_string no longer working in Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20089
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20089] email.message_from_string no longer working in Python 3.4

2013-12-28 Thread Florian Apolloner

Changes by Florian Apolloner flor...@apolloner.eu:


--
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20089
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20089] email.message_from_string no longer working in Python 3.4

2013-12-28 Thread Florian Apolloner

Florian Apolloner added the comment:

Yes, it works on python3.3 (from debian); I am parsing directly via 
email.message_from_string:
Python 3.3.3 (default, Dec  8 2013, 14:51:59) 
[GCC 4.8.2] on linux
Type help, copyright, credits or license for more information.
 import email
 msg=Content-Type: text/plain; charset=utf-8
... MIME-Version: 1.0
... Content-Transfer-Encoding: 8bit
... Subject: =?utf-8?q?Ch=C3=A8re_maman?=
... From: f...@example.com
... To: t...@example.com
... Date: Sat, 28 Dec 2013 13:08:07 -
... Message-ID: 20131228130807.3669.79195@localhost
... 
... Je t'aime très fort
 email.message_from_string(msg)
email.message.Message object at 0x7fcfbcbf9090

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20089
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

2013-09-21 Thread Florian Apolloner

New submission from Florian Apolloner:

Take the following example:

 from email.mime.nonmultipart import *
 from email.charset import *
 msg = MIMENonMultipart('text', 'plain')
 cs = Charset('utf-8')
 cs.body_encoding = None
 msg.set_payload('А Б В Г Д Е Ж Ѕ З И І К Л М Н О П.', cs)
 msg.as_string()
'MIME-Version: 1.0\nContent-Type: text/plain; 
charset=utf-8\nContent-Transfer-Encoding: 7bit\n\nА Б В Г Д Е Ж Ѕ З И І К Л М 
Н О П.'

Till python 3.3.2 this created the email as 8bit, which is in line with what 
Thunderbird creates on my box. And if I understand the RFC correctly 
(https://tools.ietf.org/html/rfc2045#section-2.7) 7bit should only be used for 
ASCII. This issue was introduced by 
http://hg.python.org/cpython/rev/64e004737837 -- I changed orig = 
msg.get_payload(decode=True) back to it's original value (decode=False) in 
encode_7or8bit and get the correct behavior again. Running the tests didn't 
cause any errors (I hope I ran the correct one).

--
components: Library (Lib)
messages: 198217
nosy: apollo13
priority: normal
severity: normal
status: open
title: Python 3.3.3  encodes emails containing non-ascii data as 7bit
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

2013-09-21 Thread Florian Apolloner

Florian Apolloner added the comment:

Am I not explicitelly disabling base64 by setting body_encoding to None?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

2013-09-21 Thread Florian Apolloner

Florian Apolloner added the comment:

Using BytesGenerator I get:
 fp = BytesIO()
 g = BytesGenerator(fp)
 msg = MIMENonMultipart('text', 'plain')
 msg.set_payload('А Б В Г Д Е Ж Ѕ З И І К Л М Н О П.', cs)
 g.flatten(msg)
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3.3/email/generator.py, line 112, in flatten
self._write(msg)
  File /usr/lib/python3.3/email/generator.py, line 177, in _write
self._dispatch(msg)
  File /usr/lib/python3.3/email/generator.py, line 203, in _dispatch
meth(msg)
  File /usr/lib/python3.3/email/generator.py, line 421, in _handle_text
super(BytesGenerator,self)._handle_text(msg)
  File /usr/lib/python3.3/email/generator.py, line 233, in _handle_text
self._write_lines(payload)
  File /usr/lib/python3.3/email/generator.py, line 158, in _write_lines
self.write(laststripped)
  File /usr/lib/python3.3/email/generator.py, line 395, in write
self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u0410' in position 
0: ordinal not in range(128)

But I might be using it wrong :/

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10808] ssl unwrap fails with Error 0

2011-01-02 Thread Florian Apolloner

New submission from Florian Apolloner flor...@apolloner.eu:

If I use the server code in the attachment I get this error in unwrap:

Traceback (most recent call last):
  File server.py, line 23, in module
deal_with_client(connstream)
  File server.py, line 13, in deal_with_client
s = connstream.unwrap()
  File /usr/lib/python3.1/ssl.py, line 302, in unwrap
s = self._sslobj.shutdown()
socket.error: [Errno 0] Error

This error message is imo far from optiomal as it gives no clue whatsoever. My 
Openssl version is: 'OpenSSL 0.9.8o 01 Jun 2010'. Aside from that 
connstream.close() doesn't close the underlying socket (as seen in 
http://bugs.python.org/issue10127 Reproduceable with py2.6 and 2.7). The only 
way to properly close the connection now is:

connstream.close(); newsocket.close()
or 
del newsocket; connstream.close()
Maybe the docs should point that out more prominent.

If you need more info just tell me.

--
components: None
files: server.py
messages: 125081
nosy: apollo13
priority: normal
severity: normal
status: open
title: ssl unwrap fails with Error 0
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20227/server.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10808
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com