[issue13955] email: RFC 2822 has been obsoleted by RFC 5322
New submission from Samuel Bronson : As you can see by looking at <http://tools.ietf.org/html/rfc2822> or <http://tools.ietf.org/html/rfc5322>, RFC 2822 has been obsoleted by RFC 5322. It would probably be a good idea to update the email package to support it, if in fact anything needs changing, and to mention/link to the new RFC in the documentation. (It would probably *not* be a good idea to stop mentioning RFC 2822, though, since that's rather more well known, and the number is a bit more memorable for those who've heard of RFC 822. I'm actually a bit surprised the new one didn't get numbered 5822...) -- components: Library (Lib) messages: 152772 nosy: SamB priority: normal severity: normal status: open title: email: RFC 2822 has been obsoleted by RFC 5322 versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13955> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13957] parsedate_tz doesn't distinguish -0000 from +0000
New submission from Samuel Bronson :
This is what I'm seeing:
>>> import email.utils
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 +')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
But RFC 5322 says:
>minutes). The form "+" SHOULD be used to indicate a time zone at
>Universal Time. Though "-" also indicates Universal Time, it is
>used to indicate that the time was generated on a system that may be
>in a local time zone other than Universal Time and that the date-time
>contains no information about the local time zone.
(As does RFC 2822, which RFC 5322 obsoletes.)
And the documentation for email.utils.parsedate_tz is:
> Performs the same function as parsedate(), but returns either None or a
> 10-tuple; the first 9 elements make up a tuple that can be passed directly to
> time.mktime(), and the tenth is the offset of the date’s timezone from UTC
> (which is the official term for Greenwich Mean Time) [1]. If the input string
> has no timezone, the last element of the tuple returned is None. Note that
> indexes 6, 7, and 8 of the result tuple are not usable.
So it seems like I should have seen:
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, None)
--
components: Library (Lib)
messages: 152774
nosy: SamB
priority: normal
severity: normal
status: open
title: parsedate_tz doesn't distinguish - from +
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13957>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1054041] Python doesn't exit with proper resultcode on SIGINT
Changes by Samuel Bronson : -- nosy: +SamB ___ Python tracker <http://bugs.python.org/issue1054041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Samuel Bronson added the comment: Um ... any progress on reviewing this? -- nosy: +SamB ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1284316] Win32: Security problem with default installation directory
Samuel Bronson added the comment: Um, you know this still affects Python 2.7 right? Yes, I realize that it's not going to be very practical to change the default installation path for 2.7, but that doesn't make the issue disappear, nor is that the only way to close the hole. Which is to say, the 2.7 installer should be changed to tighten the permissions on the installation directory when doing an "all-users" install (even if the directory already exists, though in that case it might make sense for it to be optional). (I suppose the same logic applies to any other version < 3.5 that's still getting security updates, too?) P.S. Does this count as CVE-2012-5379, even though that was reported against ActiveState's distribution? I'm pretty sure it's an instance of CWE-276 <https://cwe.mitre.org/data/definitions/276.html>, at any rate. -- nosy: +SamB versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue1284316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
