Re: [Django] #36711: Make createsuperuser in non-interactive mode observe AUTH_PASSWORD_VALIDATORS (was: createsuperuser in non-interactive mode bypasses AUTH_PASSWORD_VALIDATORS)

[Django]

#36711: Make createsuperuser in non-interactive mode observe
AUTH_PASSWORD_VALIDATORS
------------------------------+--------------------------------------
Reporter: stan shaw | Owner: stan shaw
Type: New feature | Status: closed
Component: contrib.auth | Version: 5.2
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Changes (by Jacob Walls):

* resolution: => wontfix
* status: assigned => closed
* summary:
createsuperuser in non-interactive mode bypasses
AUTH_PASSWORD_VALIDATORS
=>
Make createsuperuser in non-interactive mode observe
AUTH_PASSWORD_VALIDATORS
* type: Bug => New feature

Comment:

Password validation in `createsuperuser` was discussed at length on the
old mailing list:
https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m/r_-7uRIuAgAJ

I grant that there's an inconsistency here given that the other variables
are cleaned:

{{{
DJANGO_SUPERUSER_EMAIL=garbage ./manage.py createsuperuser --no-input
--username jane
}}}
{{{
CommandError: Enter a valid email address.
}}}

... but I don't think validating this password takes account of the fact
that `createsuperuser` is a convenience for an administrator who's tasked
with choosing a secure password and can set it themselves in a shell, as
opposed to setting a password policy for users.

This would be a breaking change, see the
[https://github.com/search?q=DJANGO_SUPERUSER_PASSWORD&type=code&p=1
overwhelming usage] of this feature to set dummy passwords for
development.

Requiring dummy development passwords to be strong could even nudge users
into a false sense of security, by encouraging reuse of a password
committed to version control in production because it "looks secure", as
mentioned [https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m
/r_-7uRIuAgAJ here].

I'll close as wontfix according to our triage process, but feel free to
pursue this further on the Django forum to see what others think.

----
I'd be open to a PR logging a warning (as `Refs #36711 --`), in the spirit
of Carl's advice that led to the interactive prompt to bypass validation
from #28571:

> So it's good to remind them of the validation fail, but there's no
reason to make their life difficult.
--
Ticket URL: <https://code.djangoproject.com/ticket/36711#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.