Badsignature on uwsgi-error.log
Hi,
I keep receiving a lot of errors like this:
--- Logging error --- Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 356, in pusher task = SignedPackage.loads(task[1]) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py", line 25, in loads return signing.loads( File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 35, in loads base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s, max_age=max_age)) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 70, in unsign result = super(TimestampSigner, self).unsign(value) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/usr/lib/python3.10/logging/__init__.py", line 1100, in emit msg = self.format(record) File "/usr/lib/python3.10/logging/__init__.py", line 943, in format return fmt.format(record) File "/usr/lib/python3.10/logging/__init__.py", line 678, in format record.message = record.getMessage() File "/usr/lib/python3.10/logging/__init__.py", line 368, in getMessage msg = msg % self.args TypeError: not all arguments converted during string formatting Call stack: File "/local/mailman/venv/bin/mailman-web", line 8, in <module> sys.exit(main()) File "/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py", line 90, in main execute_from_command_line(sys.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv self.execute(*args, **cmd_options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute output = self.handle(*args, **options) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/management/commands/qcluster.py", line 22, in handle q.start() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 78, in start self.sentinel.start() File "/usr/lib/python3.10/multiprocessing/process.py", line 121, in start self._popen = self._Popen(self) File "/usr/lib/python3.10/multiprocessing/context.py", line 224, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/context.py", line 281, in _Popen return Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 71, in _launch code = process_obj._bootstrap(parent_sentinel=child_r) File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap self.run() File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 168, in __init__ self.start() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 172, in start self.spawn_cluster() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 248, in spawn_cluster self.pusher = self.spawn_pusher() File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 201, in spawn_pusher return self.spawn_process(pusher, self.task_queue, self.event_out, self.broker) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 197, in spawn_process p.start() File "/usr/lib/python3.10/multiprocessing/process.py", line 121, in start self._popen = self._Popen(self) File "/usr/lib/python3.10/multiprocessing/context.py", line 224, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/context.py", line 281, in _Popen return Popen(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 71, in _launch code = process_obj._bootstrap(parent_sentinel=child_r) File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap self.run() File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 358, in pusher logger.error(e, traceback.format_exc()) Message: BadSignature('Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match') Arguments: ('Traceback (most recent call last):\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 356, in pusher\n task = SignedPackage.loads(task[1])\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py", line 25, in loads\n return signing.loads(\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 35, in loads\n base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s, max_age=max_age))\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 70, in unsign\n result = super(TimestampSigner, self).unsign(value)\n File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign\n raise BadSignature(\'Signature "%s" does not match\' % sig)\ndjango.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match\n',)
The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same.
Any clue what could be the issue?
And this is on the latest mailman.
pip freeze aiosmtpd==1.4.4.post2 alembic==1.13.1 arrow==1.3.0 asgiref==3.7.2 atpublic==4.0 attrs==23.2.0 authheaders==0.16.2 authres==1.2.0 blessed==1.20.0 certifi==2024.2.2 cffi==1.16.0 charset-normalizer==3.3.2 click==8.1.7 cmarkgfm==2024.1.14 cryptography==42.0.3 defusedxml==0.7.1 Django==4.1.13 django-allauth==0.61.1 django-appconf==1.0.6 django-compressor==4.4 django-extensions==3.2.3 django-gravatar2==1.4.4 django-haystack==3.2.1 django-mailman3==1.3.11 django-picklefield==3.1 django-q==1.3.9 djangorestframework==3.14.0 dkimpy==1.1.5 dnspython==2.5.0 docutils==0.20.1 falcon==3.1.3 flufl.bounce==4.0 flufl.i18n==5.0.2 flufl.lock==8.0.2 greenlet==3.0.3 gunicorn==21.2.0 HyperKitty==1.3.8 idna==3.6 lazr.config==3.0 lazr.delegates==2.1.0 mailman==3.3.9 mailman-hyperkitty==1.2.1 mailman-web==0.0.8 mailmanclient==3.3.5 Mako==1.3.2 MarkupSafe==2.1.5 mistune==2.0.5 mysql==0.0.3 mysqlclient==2.2.4 networkx==3.2.1 nh3==0.2.15 oauthlib==3.2.2 packaging==23.2 passlib==1.7.4 postorius==1.3.10 psutil==5.9.8 publicsuffix2==2.20191221 pycparser==2.21 Pygments==2.17.2 PyJWT==2.8.0 PyMySQL==1.1.0 python-dateutil==2.8.2 python3-openid==3.2.0 pytz==2024.1 rcssmin==1.1.1 readme-renderer==42.0 redis==3.5.3 requests==2.31.0 requests-oauthlib==1.3.1 rjsmin==1.2.1 robot-detection==0.4 six==1.16.0 SQLAlchemy==2.0.27 sqlparse==0.4.4 types-python-dateutil==2.8.19.20240106 typing_extensions==4.9.0 urllib3==2.2.0 uWSGI==2.0.24 wcwidth==0.2.13 Whoosh==2.7.4 xapian @ file:///local/mailman/xapian-1.4.23-cp310-cp310-linux_x86_64.whl zope.component==6.0 zope.configuration==5.0.1 zope.event==5.0 zope.hookable==6.0 zope.i18nmessageid==6.1.0 zope.interface==6.2 zope.schema==7.0.1
Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro
On 3/20/24 14:25, Helio Loureiro wrote:
Hi,
I keep receiving a lot of errors like this:
--- Logging error --- Traceback (most recent call last): ... "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match ...
The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same.
Of those three, the api_key on mailman-hypperkitty.cfg and MAILMAN_ARCHIVE_KEY must match. SECRET_KEY is different. It is a Django thing and has nothing to do with the others. See https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key
If you changed it, that's the issue. If you know what it was previously, you could set the previous value in SECRET_KEY_FALLBACKS, see https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key-fallbacks
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
Thanks for your response. I found what the issue was.
I actually misspelled hyperkitty as hyPperkitty on the url.
So the error on mailman-hyperkitty.cfg was:
base_url: http://localhost:8000/hypperkitty/
I moved to:
base_url: http://localhost:8000/hyperkitty/
and it was solved.
Problem was the wrong link was getting a generic page from Django instead of error. And it was failing to do the parsing probably, which was taking wrongly as key mistake. Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro
On Thu, 21 Mar 2024 at 01:13, Mark Sapiro <mark@msapiro.net> wrote:
On 3/20/24 14:25, Helio Loureiro wrote:
Hi,
I keep receiving a lot of errors like this:
--- Logging error --- Traceback (most recent call last): ...
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match ...
The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same.
Of those three, the api_key on mailman-hypperkitty.cfg and MAILMAN_ARCHIVE_KEY must match. SECRET_KEY is different. It is a Django thing and has nothing to do with the others. See https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key
If you changed it, that's the issue. If you know what it was previously, you could set the previous value in SECRET_KEY_FALLBACKS, see https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key-fallbacks
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to helio@loureiro.eng.br
Hi,
I was wrong. It keeps happening. So the base_url didn't fix the issue.
And the keys are the same in all configurations.
Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro
On Fri, 22 Mar 2024 at 09:37, Helio Loureiro <helio@loureiro.eng.br> wrote:
Hi Mark,
Thanks for your response. I found what the issue was.
I actually misspelled hyperkitty as hyPperkitty on the url.
So the error on mailman-hyperkitty.cfg was:
base_url: http://localhost:8000/hypperkitty/
I moved to:
base_url: http://localhost:8000/hyperkitty/
and it was solved.
Problem was the wrong link was getting a generic page from Django instead of error. And it was failing to do the parsing probably, which was taking wrongly as key mistake. Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro
On Thu, 21 Mar 2024 at 01:13, Mark Sapiro <mark@msapiro.net> wrote:
On 3/20/24 14:25, Helio Loureiro wrote:
Hi,
I keep receiving a lot of errors like this:
--- Logging error --- Traceback (most recent call last): ...
"/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py",
line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match ...
The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same.
Of those three, the api_key on mailman-hypperkitty.cfg and MAILMAN_ARCHIVE_KEY must match. SECRET_KEY is different. It is a Django thing and has nothing to do with the others. See https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key
If you changed it, that's the issue. If you know what it was previously, you could set the previous value in SECRET_KEY_FALLBACKS, see https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key-fallbacks
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to helio@loureiro.eng.br
Helio Loureiro writes:
Problem was the wrong link was getting a generic page from Django instead of error.
You can set DEBUG = True in settings.py, which will give you a much more informative error page, including a lot of information that you can't easily get from logs and configuration files.
HOWEVER, this also gives all that information to anybody who can induce an error, which of course is not that hard to do. You may want to take the server offline by firewalling it off, do some experimenting with DEBUG = True, then set it back to DEBUG = False before bringing it back up.
Of those three, the api_key on mailman-hypperkitty.cfg and MAILMAN_ARCHIVE_KEY must match. SECRET_KEY is different. It is a Django thing and has nothing to do with the others. See https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key
If you changed it, that's the issue.
Have you changed that key?
Hi Mark & all,
Thanks for the response. Just picking up where we are at the moment to provide a bit more info, in case you have ideas. Thanks, Stephen T. as well for the idea of turning on DEBUG. We might resort to that in the end.
This is what our system is running right now:
Mailman Core Version GNU Mailman 3.3.9 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]
As previously noted, we moved this off of an old Ubuntu package-based installation that has delivered mail reliably but many other things haven't worked well, so we're happy to be on something that might improve that situation.
Right now, archiving is not working on the new installation, both building the archive on the new installation after the move and for new messages.
uwsgi-error.log is getting blasted with constant errors along the lines of what follows. I suspect that these errors are why archiving isn't working, but I obviously don't know that:
Message: BadSignature('Signature "ZWBXqQmWZwHTfa390lLIacpp8NQ" does not match') Arguments: ('Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django_q/cluster.py", line 356, in pusher task = SignedPackage.loads(task[1]) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/signing.py", line 25, in loads return signing.loads( File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 35, in loads base64d = force_bytes(TimestampSigner(key, salt=salt).unsign(s, max_age=max_age)) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 70, in unsign result = super(TimestampSigner, self).unsign(value) File "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature(\'Signature "%s" does not match\' % sig) django.core.signing.BadSignature: Signature "ZWBXqQmWZwHTfa390lLIacpp8NQ" does not match',)
What we have in our config files on the old installation and new installation are (the quotes are exactly as they are in the files):
Old installation:
mailman-web.py
SECRET_KEY = 'somerandomstringiaintputtinginmail' MAILMAN_ARCHIVER_KEY = 'somerandomstringiaintputtinginmail'
mailman-hyperkitty.cfg
api_key: somerandomstringiaintputtinginmail
New installation:
settings.py
SECRET_KEY = 'somerandomstringiaintputtinginmail' MAILMAN_ARCHIVER_KEY = 'somerandomstringiaintputtinginmail'
mailman-hyperkitty.cfg
api_key: somerandomstringiaintputtinginmail
All of that says that the value is the same for all three (whether I should have done so or not...) and those settings were carried along to the new installation as well.
Django is a big scary beast as I've not had to manage django apps before. Would it make sense that the error above is because what I _think_ django believes is the SECRET_KEY (in the config files above) is in fact not what django believes? Maybe it was set during installation (which I didn't do)? I don't believe anyone has purposefully changed it.
I suppose I could do something like https://medium.com/django-unleashed/securing-django-applications-best-practi... to reset the secret key, but I'm not doing that on Friday afternoon :)
If anyone has other thoughts, please holler. Wishing you all a good weekend from lighter-by-the-day Sweden.
Cheers,
David
-----Original Message----- From: Mark Sapiro <mark@msapiro.net<mailto:Mark%20Sapiro%20%3cmark@msapiro.net%3e>> To: mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> Subject: [MM3-users] Re: Badsignature on uwsgi-error.log Date: Wed, 20 Mar 2024 18:12:20 -0700
On 3/20/24 14:25, Helio Loureiro wrote: Hi,
I keep receiving a lot of errors like this:
--- Logging error --- Traceback (most recent call last): ... "/local/mailman/venv/lib/python3.10/site-packages/django_q/core_signing.py", line 55, in unsign raise BadSignature('Signature "%s" does not match' % sig) django.core.signing.BadSignature: Signature "F6V0Dr_SvBsx5-cY8vcvLXrX8tA" does not match ...
The api_key on mailman-hypperkitty.cfg, SECRET_KEY and MAILMAN_ARCHIVE_KEY on setting.py are the same.
Of those three, the api_key on mailman-hypperkitty.cfg and MAILMAN_ARCHIVE_KEY must match. SECRET_KEY is different. It is a Django thing and has nothing to do with the others. See https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key
If you changed it, that's the issue. If you know what it was previously, you could set the previous value in SECRET_KEY_FALLBACKS, see https://docs.djangoproject.com/en/5.0/ref/settings/#secret-key-fallbacks
On 3/22/24 09:48, David Partain via Mailman-users wrote:
Right now, archiving is not working on the new installation, both building the archive on the new installation after the move and for new messages.
uwsgi-error.log is getting blasted with constant errors along the lines of what follows. I suspect that these errors are why archiving isn't working, but I obviously don't know that:
Message: BadSignature('Signature "ZWBXqQmWZwHTfa390lLIacpp8NQ" does not match')
I'm not sure if this is the issue with archiving or not.
What we have in our config files on the old installation and new installation are (the quotes are exactly as they are in the files): ... settings.py
SECRET_KEY = 'somerandomstringiaintputtinginmail' MAILMAN_ARCHIVER_KEY = 'somerandomstringiaintputtinginmail'
mailman-hyperkitty.cfg
api_key: somerandomstringiaintputtinginmail
All of that says that the value is the same for all three (whether I should have done so or not...) and those settings were carried along to the new installation as well.
See my reply at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
As I say there, SECRET_KEY is not related in any way to MAILMAN_ARCHIVER_KEY and api_key. The latter two have to do with archiving and must match. The former is a Django thing and is completely separate.
At this point, put
SECRET_KEY_FALLBACKS = [
'F6V0Dr_SvBsx5-cY8vcvLXrX8tA',
'ZWBXqQmWZwHTfa390lLIacpp8NQ',
]
in your local Django settings file. If you continue to get BadSignature: Signature "..." does not match' errors, add those unmatched signatures to SECRET_KEY_FALLBACKS.
Once you are no longer seeing BadSignature errors, if archiving is still not working, report any errors you are seeing from Mailman's mailman.log and Django's log.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
David Partain -
Helio Loureiro -
Mark Sapiro -
Stephen J. Turnbull