#35930: Database password visible on debug page in local variable
-------------------------------------+-------------------------------------
Reporter: bytej4ck | Owner: Baha
Type: | Sdtbekov
Cleanup/optimization | Status: new
Component: Error reporting | Version: dev
Severity: Normal | Resolution:
Keywords: db, password, | Triage Stage: Accepted
exposed |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):
* stage: Unreviewed => Accepted
* type: Bug => Cleanup/optimization
Comment:
Replying to [comment:7 Jacob Walls]:
> Yeah, the failure has to be "occasional" enough to not prevent the
development server from booting. I know this is lazier than writing a unit
test, but two quick reproducers:
> - Start your db, boot the development server, stop the db, and visit
another page that makes a db query.
> - Or, while keeping your db up, fiddle with simulating a "random"
failure like this:
Thank you Jacob, I assumed so and I did try both of these before, but the
bit that I was missing was to actually "go" to the DB to fetch or write
something. In retrospect, this is obvious, but somehow I missed it. I
managed to reproduce the issue, but as anticipated, I fear that this
ticket, if accepted, has a scope beyond handling only `connect`.
Specifically, if accepted, we should at least:
* mark as sensitive every location that uses the connection params via
calling `get_connection_params`
* mark as sensitive `settings_dict` and `conn_params` in
`get_connection_params`
* audit the rest of the code for other parts using or accessing the DB
settings/password in any way
I'm not convinced this is within the scope of what Django core should
handle. It has always been stated that
[https://docs.djangoproject.com/en/5.1/howto/error-reporting/#filtering-
error-reports error report filtering is a best-effort solution] and
further measures should be taken to sanitize or guard the error logs.
Despite my reservations, I'm inclined to accept this, as it could provide
a clear improvement by carefully adding the `sensitive_variables`
decorator to the audited methods and functions.
Regarding Baha's comments, I think we should limit this ticket to "DB
connection params" and avoid expanding the scope, as it’s better to focus
on one specific issue. In summary, I'm accepting with the
rationale/caveats expressed above.
--
Ticket URL: <https://code.djangoproject.com/ticket/35930#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/01070193741b6069-8f1a9249-30e3-4443-8715-d24d4de3c5c3-000000%40eu-central-1.amazonses.com.
