I'm not sure if this is a bug or something about the new CSRF fix doesn't get along with something I have (mis)configured, but this definitely seems to be related. Sadly the script I use to backup mailman before upgrading I recently stopped backing up the lists themselves, so going back to 2.1.35 doesn't seem to be an option due to the .pck file version bump. Here's the trace I get:
Traceback (most recent call last):
File "/mailman/mailman-${domainslug}/scripts/driver", line 117, in
run_main
main()
File "/mailman/mailman-${domainslug}/Mailman/Cgi/admindb.py", line
342, in main
print doc.Format()
File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line
352, in Format
output.append(Container.Format(self, indent))
File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line
267, in Format
output.append(HTMLFormatObject(item, indent))
File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 53,
in HTMLFormatObject
return item.Format(indent)
File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line
445, in Format
% csrf_token(self.mlist, self.contexts, self.user)
File "/mailman/mailman-${domainslug}/Mailman/CSRFcheck.py", line 53,
in csrf_token
mac = sha_new(secret + issued
).hexdigest()
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
Running Python 2.7.5 .
Joel Lord
Well, I found a workaround that may have completely obviated this. I found instructions for individually handling outstanding moderator requests from the command line using withlist, and went through and flushed the 7 spammy requests that were in there. (I'd forgotten to include that this traceback was triggered from a single list's admindb URL.) With request.pck down to 20 bytes, we're back to normal.
I'm going to presume that there were requests in there that were somehow corrupted by the upgrade process?
On 11/12/2021 4:06 PM, Joel Lord wrote:
I'm not sure if this is a bug or something about the new CSRF fix doesn't get along with something I have (mis)configured, but this definitely seems to be related. Sadly the script I use to backup mailman before upgrading I recently stopped backing up the lists themselves, so going back to 2.1.35 doesn't seem to be an option due to the .pck file version bump. Here's the trace I get:
Traceback (most recent call last): File "/mailman/mailman-${domainslug}/scripts/driver", line 117, in run_main main() File "/mailman/mailman-${domainslug}/Mailman/Cgi/admindb.py", line 342, in main print doc.Format() File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 352, in Format output.append(Container.Format(self, indent)) File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 267, in Format output.append(HTMLFormatObject(item, indent)) File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 53, in HTMLFormatObject return item.Format(indent) File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 445, in Format % csrf_token(self.mlist, self.contexts, self.user) File "/mailman/mailman-${domainslug}/Mailman/CSRFcheck.py", line 53, in csrf_token mac = sha_new(secret +
issued
).hexdigest() TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'Running Python 2.7.5 .
-- Joel Lord
On 11/12/21 1:06 PM, Joel Lord wrote:
I'm not sure if this is a bug or something about the new CSRF fix doesn't get along with something I have (mis)configured, but this definitely seems to be related. Sadly the script I use to backup mailman before upgrading I recently stopped backing up the lists themselves, so going back to 2.1.35 doesn't seem to be an option due to the .pck file version bump. Here's the trace I get:
Traceback (most recent call last): File "/mailman/mailman-${domainslug}/scripts/driver", line 117, in run_main main() File "/mailman/mailman-${domainslug}/Mailman/Cgi/admindb.py", line 342, in main print doc.Format() File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 352, in Format output.append(Container.Format(self, indent)) File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 267, in Format output.append(HTMLFormatObject(item, indent)) File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 53, in HTMLFormatObject return item.Format(indent) File "/mailman/mailman-${domainslug}/Mailman/htmlformat.py", line 445, in Format % csrf_token(self.mlist, self.contexts, self.user) File "/mailman/mailman-${domainslug}/Mailman/CSRFcheck.py", line 53, in csrf_token mac = sha_new(secret +
issued
).hexdigest() TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'Running Python 2.7.5 .
Thanks for the report. I think the issue is caused by the fix for https://bugs.launchpad.net/mailman/+bug/1949403 and can occur when a list admin is trying to handle moderator requests on a list that has no moderator password. I'll investigate and try to put out another fix later today.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/12/2021 5:25 PM, Mark Sapiro wrote:
Thanks for the report. I think the issue is caused by the fix for https://bugs.launchpad.net/mailman/+bug/1949403 and can occur when a list admin is trying to handle moderator requests on a list that has no moderator password. I'll investigate and try to put out another fix later today.
The list definitely has a moderator password, but I'm not certain that the site had a sitepass set. I had to set one to get in and look around.
-- Joel Lord
On 11/12/2021 5:25 PM, Mark Sapiro wrote:
Thanks for the report. I think the issue is caused by the fix for https://bugs.launchpad.net/mailman/+bug/1949403 and can occur when a list admin is trying to handle moderator requests on a list that has no moderator password. I'll investigate and try to put out another fix later today.
Just realized I misread your statement. No, these lists don't have any "moderators", so they don't have a moderator password set. Just admins, doing both roles.
-- Joel Lord
On 11/12/21 3:47 PM, Joel Lord wrote:
On 11/12/2021 5:25 PM, Mark Sapiro wrote:
Thanks for the report. I think the issue is caused by the fix for https://bugs.launchpad.net/mailman/+bug/1949403 and can occur when a list admin is trying to handle moderator requests on a list that has no moderator password. I'll investigate and try to put out another fix later today.
Just realized I misread your statement. No, these lists don't have any "moderators", so they don't have a moderator password set. Just admins, doing both roles.
Yes, the issue occurs when logging in to the admindb with the admin or site password on a list with moderator requests and no moderator password set. It is fixed in Mailman 2.1.37 which I just released (announcement to follow).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Joel Lord
-
Mark Sapiro