| From: | Denis Smirnov <darthunix(at)gmail(dot)com> |
|---|---|
| To: | Grigorev Jurij <ju(dot)grigorev(at)ftdata(dot)ru> |
| Cc: | Diego <mrstephenamell(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] libpq: Add PQpassfileLookup() |
| Date: | 2026-09-13 05:20:40 |
| Message-ID: | D35D0ABB-755E-4EDE-B535-5C7578B3D3DC@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Diego,
Thanks for v2!
> * The returned allocation contains a plaintext password.
> PQfreemem() does not erase it, whereas libpq explicitly clears
> passwords stored in PGconn before freeing them. It would be useful
> for the documentation to mention that callers are responsible for
> securely clearing the result where appropriate.
The new docs now say this, but passwordFromFile() leaves part of the
original password after removing escapes in place:
Password in .pgpass: pa\\ss\:word
Returned buffer: pa\ss:word\0d\0
A caller using explicit_bzero(password, strlen(password)) before
PQfreemem() leaves the final 'd' untouched. Could we zero this tail in
passwordFromFile() before returning? The caller does not know the
original allocation size.
Best regards,
Denis Smirnov
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Alexander Korotkov | 2026-09-12 21:06:56 | Re: Implement waiting for wal lsn replay: reloaded |