------------------------------------------------------------
revno: 1665
fixes bug: https://launchpad.net/bugs/1604544
committer: Mark Sapiro <m...@msapiro.net>
branch nick: 2.1
timestamp: Tue 2016-07-19 12:23:32 -0700
message:
Membership List letter links could be incorrectly rendered as Unicode.
modified:
Mailman/Cgi/admin.py
NEWS
--
lp:mailman/2.1
https://code.launchpad.net/~mailman-coders/mailman/2.1
Your team Mailman Checkins is subscribed to branch lp:mailman/2.1.
To unsubscribe from this branch go to
https://code.launchpad.net/~mailman-coders/mailman/2.1/+edit-subscription
=== modified file 'Mailman/Cgi/admin.py'
--- Mailman/Cgi/admin.py 2016-07-14 21:27:49 +0000
+++ Mailman/Cgi/admin.py 2016-07-19 19:23:32 +0000
@@ -1010,6 +1010,9 @@
if regexp:
findfrag = '&findmember=' + urllib.quote(regexp)
url = adminurl + '/members?letter=' + letter + findfrag
+ if isinstance(url, unicode):
+ url = url.encode(Utils.GetCharSet(mlist.preferred_language),
+ errors='ignore')
if letter == bucket:
show = Bold('[%s]' % letter.upper()).Format()
else:
=== modified file 'NEWS'
--- NEWS 2016-07-15 02:10:24 +0000
+++ NEWS 2016-07-19 19:23:32 +0000
@@ -9,30 +9,30 @@
New Features
- - For header_filter_rules matching, both RFC 2047 encoded headers and
- header_filter_rules patterns are now decoded to unicode as are. Both
- XML character references of the form &#nnnn; and unicode escapes of the
- form \Uxxxx in patterns are converted to unicodes as well. Both headers
- and patterns are normalized to 'NFKC' normal form before matching, but
- the normalization form can be set via a new NORMALIZE_FORM mm_cfg
- setting. Also, the web UI has been updated to encode characters in text
- fields that are invalid in the character set of the page's language as
- XML character references instead of '?'. This should help with entering
- header_filter_rules patterns to match 'odd' characters. This feature is
- experimental and is problematic for some cases where it is desired to
- have a header_filter_rules pattern with characters not in the character
- set of the list's preferred language. For patterns without such
- characters, the only change in behavior should be because of unicode
- normalization which should improve matching. For other situations such
- as trying to match a Subject: with CJK characters (range U+4E00..U+9FFF)
- on an English language (ascii) list, one can enter a pattern like
- '^subject:.*[一-鿿]' or '^subject:.*[\u4e00;-\u9fff;]' to
- match a Subject with any character in the range, and it will work, but
- depending on the actual characters and the browser, submitting another,
- even unrelated change can garble the original entry although this
- usually occurs only with ascii pages and characters in the range
- \u0080-\u00ff. The \Uxxxx unicode escapes must have exactly 4 hex
- digits, but they are case insensitive. (LP: #558155)
+ - For header_filter_rules matching, RFC 2047 encoded headers, non-encoded
+ headers and header_filter_rules patterns are now all decoded to unicode.
+ Both XML character references of the form &#nnnn; and unicode escapes
+ of the form \Uxxxx in patterns are converted to unicodes as well. Both
+ headers and patterns are normalized to 'NFKC' normal form before
+ matching, but the normalization form can be set via a new NORMALIZE_FORM
+ mm_cfg setting. Also, the web UI has been updated to encode characters
+ in text fields that are invalid in the character set of the page's
+ language as XML character references instead of '?'. This should help
+ with entering header_filter_rules patterns to match 'odd' characters.
+ This feature is experimental and is problematic for some cases where it
+ is desired to have a header_filter_rules pattern with characters not in
+ the character set of the list's preferred language. For patterns
+ without such characters, the only change in behavior should be because
+ of unicode normalization which should improve matching. For other
+ situations such as trying to match a Subject: with CJK characters (range
+ U+4E00..U+9FFF) on an English language (ascii) list, one can enter a
+ pattern like '^subject:.*[一-鿿]' or
+ '^subject:.*[\u4e00;-\u9fff;]' to match a Subject with any character in
+ the range, and it will work, but depending on the actual characters and
+ the browser, submitting another, even unrelated change can garble the
+ original entry although this usually occurs only with ascii pages and
+ characters in the range \u0080-\u00ff. The \Uxxxx unicode escapes must
+ have exactly 4 hex digits, but they are case insensitive. (LP: #558155)
- Thanks to Jim Popovitch REMOVE_DKIM_HEADERS can now be set to 3 to
preserve the original headers as X-Mailman-Original-... before removing
@@ -65,6 +65,9 @@
Bug fixes and other patches
+ - The admin Membership List letter links could be incorrectly rendered as
+ Unicode strings following a search. (LP: #1604544)
+
- We no longer throw an uncaught TypeError with certain defective crafted
POST requests to Mailman's CGIs. (LP: #1602608)
_______________________________________________
Mailman-checkins mailing list
Mailman-checkins@python.org
Unsubscribe:
https://mail.python.org/mailman/options/mailman-checkins/archive%40jab.org
