If by "still seeing the error" you mean that the default options.html
template generates the "suspicious html" message in the GUI editor, then
I don't understand why, because that was fixed in 2.1.12 as you gather,
by adding a negative lookahead to except that specific <link> tag.
If you mean just that the test is too strict because it thinks various
innocent tags are suspicious, then yes, you are correct. It does that.
And, it should be a whitelist rather than a blacklist which would make
it even stricter.
It is not intended to be a 100% perfect XSS detector or even close. It
is intended to require that anything remotely suspicious be installed by
an admin with shell access. This doesn't mean that list admins should be
given shell access to do this. That would defeat the whole purpose of
the test. It means that only a site admin has authority to bypass the
test.
As I said, the web interface will be redone completely for MM 3. It is
not clear that this will have any relevance there, but if you wish to
submit an RFE for the "trusted list admin" option that would allow list
admins to alter the web interface for their list in any way they wish,
please do,
However, nothing is likely to change on the 2.1 branch.
--
Error while editiing general list information page
https://bugs.launchpad.net/bugs/266273
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Oops, sorry. I was trying too hard not to create a duplicate, and am
surprised it isn't already on launchpad, having seen the Sourceforge
report you mention. Should I resubmit as a new bug/request?
I'm using 2.1.12 and still seeing the error - I gather the fix was to
add a lookahead exclusion based on the current options template. Having
seen quite a few recent injected HTML attacks on the lines of Gumblar, I
wonder if it would be adequate to block on the basis only of meta
refresh, iframe, script src= and certain JS keywords like unescape and
str_replace; on the other hand, the badwords list is probably not that
comprehensive: it doesn't exclude possible XSS routes like embed, object
or the obscure table background=javascript:....
IMHO a "trusted list admin" option would cover most needs most easily -
giving SSH access to an (untrusted?) user might create greater security
problems.
I shared the list administrator's misunderstanding of the FAQ reference
because of context.
--
Error while editiing general list information page
https://bugs.launchpad.net/bugs/266273
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
You have hijacked a totally different (invalid) bug report. This
original 'bug' is the result of a lack of permission to create or write
the lists/LISTNAME/en/listinfo.html file.
The SF bug #2164798 which is relevant to your issue was created after
the migration to Launchpad as noted in that bug. That bug was closed and
was fixed in Mailman 2.1.12.
The web interface will be entirely redone for MM 3 and this is unlikely
to be an issue there. I did consider a "trusted list admin" option for
the suspicious HTML check, but decided against it.
Also note that the reference to FAQ 4.48 is not intended to explain the
"suspicious html". It is intended to explain how to install the template
without triggering the check.
--
Error while editiing general list information page
https://bugs.launchpad.net/bugs/266273
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
** Changed in: mailman
Milestone: None => 2.1.12
--
Error while editiing general list information page
https://bugs.launchpad.net/bugs/266273
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
It looks like a few people (eg on Sourceforge) have reported that the
suspicious HTML check is too suspicious since it was introduced in
version 2.1.9; for instance rejecting innocent META tags. Also, it
links to http://wiki.list.org/x/jYA9 for more information, but there is
no information there about the reasons for rejection leading to
frustration for the list owner.
"The page you saved contains suspicious HTML that could potentially expose your users to cross-site scripting attacks. This change has therefore been rejected. If you still want to make these changes, you must have shell access to your Mailman server.
See FAQ 4.48."
Could either the list of "badwords" be moved to Defaults.py, or there be
an option to say that we trust list owners to edit their own HTML?
I've worked around by hacking /usr/lib/mailman/Mailman/Cgi/edithtml.py
line 162.
** Changed in: mailman
Status: New => Confirmed
--
Error while editiing general list information page
https://bugs.launchpad.net/bugs/266273
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Fixed at rev 1220 on the 2.1 branch and rev 1093 on the 2.2 branch.
The fix is probably still incomplete. I think there will still be issues
when long subjects are folded and unfolded. A possible fix is to remove
all white space from 'stripped' subjects or maybe replace all runs of
whitespace with a single space.
** Changed in: mailman
Status: Triaged => Fix Committed
** Branch linked: lp:mailman/2.1
** Branch linked: lp:mailman/2.2
--
Fix to fallback of thread by subject
https://bugs.launchpad.net/bugs/266572
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
This bug is for Mailman 2.1.x. Checking the mailman/2.1 branch shows
that the problem still exists there. I am aware the focus is now on the
3.x branches. I am reporting this in case development is still being
done on this branch.
Pipermail has indexes by subject, author and date. It stores by a tuple
typed key.
When doing the default threading approach, HyperDatabase calls
getOldestArticle with the subject.
def getOldestArticle(self, archive, subject):
self.__openIndices(archive)
subject = subject.lower()
try:
key, tempid=self.subjectIndex.set_location(subject)
self.subjectIndex.next()
[subject2, date]= key.split('\0')
if subject!=subject2: return None
return tempid
except KeyError:
return None
Note the key used in the index operation is a string. This will always
fail, because it is not the specialised article specific tuple that was
actually used as a key by pipermail.
This bug was also reported here (but is attached to a milestone I cannot change):
https://bugs.launchpad.net/mailman/+bug/266572
** Affects: mailman
Importance: Undecided
Status: New
--
mailman archiving sorting broken
https://bugs.launchpad.net/bugs/519654
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
This bug is still valid, but the patch is incomplete at best.
Preliminary testing shows that with the patch, rebuilding the archive
with bin/arch --wipe works generally as expected, but individual posts
without In-Reply-To: headers are still not threaded by Subject if the
list has a subject_prefix. This appears to be the case whether or not
the prefix is included in the reply as sent. The posts are unthreaded in
the archive until the archive is rebuilt with bin/arch --wipe.
** Changed in: mailman
Status: Invalid => Triaged
** Changed in: mailman
Milestone: mailman-2.0.x => 2.1-stable
** Changed in: mailman
Assignee: (unassigned) => Mark Sapiro (msapiro)
--
Fix to fallback of thread by subject
https://bugs.launchpad.net/bugs/266572
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
mailman 2.1.12
postfix 2.6.5
ubuntu 9.10/karmic
setup according to the instructions in postfix-to-mailman.py.
when postfix recipient_delimiter="-", the 'user' gets passed to postfix-
to-mailman.py with the trailing -xxx removed. mail to "list-owner" or
"list-subscribe", etc gets passed as "list". this breaks anything but
mail to the list.
i patched postfix master.cf to send the entire recipient address and
postfix-to-mailman to manually extract the username.
** Affects: mailman
Importance: Undecided
Status: New
--
postfix interacts badly with postfix-to-mailman.py when recipient_delimiter="-"
https://bugs.launchpad.net/bugs/520321
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Oops
** Changed in: mailman
Status: Invalid => Confirmed
** Changed in: mailman
Status: Confirmed => Invalid
--
Fix to fallback of thread by subject
https://bugs.launchpad.net/bugs/266572
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.