Production deployments run with PASSWORD_HASHERS=[MD5PasswordHasher] due to overly broad test override

[mgradalska]

Issue Description

A condition in karrio/server/settings/base.py intended to switch to a fast MD5 hasher only during the test suite fires for every normal runtime invocation as well, because its second predicate matches the install path of the karrio virtualenv rather than the test invocation.

As a result, every production deployment that uses the official karrio/server image runs with PASSWORD_HASHERS = ["MD5PasswordHasher"] only. Two practical consequences:

• Pre-upgrade users with PBKDF2 password hashes get locked out the moment they upgrade to 2026.1.22 or later. Their existing hash format can't be verified because no PBKDF2 hasher is loaded. Login returns "Invalid credentials" with no signal that the issue is hasher-related.
• New users get their passwords stored as MD5 - including superusers created via karrio createsuperuser, and any user signed up through the dashboard. MD5 is broken as a password hash and unsafe for storing credentials.

The override was introduced in 2026.1.22 as part of a test-suite-perf change (perf(tests+ci): test suite speed improvements and CI optimisation), and is still present on main / 2026.1.31. The changelog doesn't flag it as a breaking change. The comment next to the code claims "production is unaffected", which is what made this hard to spot.

Reproducing

With the upstream image karrio/server:2026.1.31:

# boot the image normally
docker run --rm -d --name karrio-repro \
  -e SECRET_KEY=demo -e ADMIN_EMAIL=admin@example.com -e ADMIN_PASSWORD=demo \
  -e DATABASE_ENGINE=sqlite3 \
  karrio/server:2026.1.31

# inspect PASSWORD_HASHERS via the running server's Python context
docker exec karrio-repro karrio shell -c \
  "from django.conf import settings; print(settings.PASSWORD_HASHERS)"
# → ['django.contrib.auth.hashers.MD5PasswordHasher']

For the upgrade lock-out scenario (the original cause of this report):

1. Start a Karrio 2024.12.x cluster, create an admin user. Its password is stored as pbkdf2_sha256$1200000$....
2. Upgrade the image to 2026.1.31. Migrations apply cleanly, no destructive changes.
3. Attempt to log in with the original admin credentials. The dashboard returns "Invalid credentials". The server logs AuthenticationFailed: No active account found with the given credentials, which is misleading - the user IS active and the password IS correct; only PBKDF2 hashes can't be verified, because no PBKDF2 hasher is loaded.
4. Recreate the admin via karrio createsuperuser. Login succeeds with the new credentials. Inspecting the DB, the new user's password column contains md5$<salt>$<hash>.

[mgradalska]

Opened a PR: #1096

[danh91]

Thanks @mgradalska, good catch — and for tracing it to the venv path matching the predicate.

This is a bad one: prod silently storing MD5 and locking out PBKDF2 users on upgrade. Queuing #1096 for review and merge, and we will get a patch out.