Barry A. Warsaw ba...@python.org added the comment:
I'm inclined not to support backporting to Python 2.6. It seems like a fairly
rare and narrow hole for security problem, because it would require a program
to add the bogus header explicitly, as opposed to getting it after parsing some
R. David Murray rdmur...@bitdance.com added the comment:
Well, imagine a web form that has a 'subject' text entry field, and the
application does Message['Subject'] = subject_from_form as it builds a Message
to hand off to smtp.sendmail. If the application didn't sanitize the subject
for
R. David Murray rdmur...@bitdance.com added the comment:
Ah, I should clarify. A sensible web application should be dealing with any
multiline input it allows by turning it into a newline-less single line before
using it as a subject, so the probability that there are exploitable
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5871
___
R. David Murray rdmur...@bitdance.com added the comment:
Receiving no negative votes :), I've committed this to py3k in r87873, 3.1 in
r87874, and 2.7 in r87875.
Barry, Martin, do you think this should be backported as a security fix? I'm
thinking it should be.
--
nosy: +loewis
R. David Murray rdmur...@bitdance.com added the comment:
I've considered this a bit more deeply, and it turns out to be simpler to fix
than I originally thought, assuming the fix is acceptable.
When a message is parsed we obviously wind up with headers that don't have any
embedding issues.
Changes by R. David Murray rdmur...@bitdance.com:
--
keywords: -easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5871
___
___
Python-bugs-list
Ville Lindholm ville.lindh...@gmail.com added the comment:
I tried doing a naive implementation (just checking for \n or \r in the
argument to Header) but that breaks a lot of unit tests. For example the test
message msg_16.txt contains a header like this:
Received: from cougar.noc.ucla.edu
Ray.Allen ysj@gmail.com added the comment:
Besides, not only the header value, but also the header name can only be
printable ascii characters according to RFC2822:
A field name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126,
R. David Murray rdmur...@bitdance.com added the comment:
Yeah, after I posted that suggestion it occurred to me that the newline stuff
*is* embedded in the way email5 works, but I hadn't gotten back here to post a
followup yet. I don't like it, but it is what it is. (I believe the theory is
R. David Murray rdmur...@bitdance.com added the comment:
Re __getitem__: yes, the email package allows you to work with messages that
are *not* RFC conformant (which you do encounter when processing actual email
:), and this is an important feature. The plan in email6 is to detect and
report
Terry J. Reedy tjre...@udel.edu added the comment:
My apologies for misunderstanding. Feature removal requests are sufficiently
rare that I thought you were posting a mockup of what you wanted to be able to
do, as many others have done. So we definitely agree on that example. I changed
the
R. David Murray rdmur...@bitdance.com added the comment:
Yeah, it's a good question whether or not this is enough of a behavior change
that the fix can't be backported. On the other hand, this is definitely a bug
(the RFCs specifiy that header values may not contain newlines or carriage
Terry J. Reedy tjre...@udel.edu added the comment:
Given this The email package attempts to be as RFC-compliant as possible, and
your reading, I agree this is a backport-worth bug.
This is the prohibition in the docs I was looking for.
--
___
Python
14 matches
Mail list logo
