Update "Persist Security Info" parameter description #426
Conversation
| SSL Negotiation | Controls how SSL encryption is negotiated with the server, if SSL is used. Introduced in 9.0. [See docs for possible values and more info](security.md). | PGSSLNEGOTIATION | ||
| Channel Binding | Control whether channel binding is used when authenticating with SASL. Introduced in 8.0. | Prefer | ||
| Persist Security Info | Gets or sets a Boolean value that indicates if security-sensitive information, such as the password, is not returned as part of the connection if the connection is open or has ever been in an open state. | false | ||
| Persist Security Info | When enabled, security-sensitive information, such as the password, will be included as part of connection string for tracing and logging. | false |
There was a problem hiding this comment.
Do we actually log the connection string (with the password) in logging? If so I think that's pretty questionable even when Persist Security Info is enabled... I'd prefer to review and remove this behavior...!
In my mind, this parameter was (at least originally) purely about whether reading NpgsqlConnection.ConnectionString returns the full connection string including the password (once the connection has been opened) - I don't think that it was about logging/tracing originally.
Final nit: is there anything other than the password that's actually covered here? If not, we can remove "such as the password" etc.
There was a problem hiding this comment.
My interpretation of this feature is that it comes from the OleDb C++ ages where you could really connect to a database and then (given pooling is disabled) zero out the password string after establishing a connection and then the password would really be gone from memory(-dumps).
It has never worked this way in .NET (at least for Npgsql) and reflection and the inability to zero out strings in a garbage collection environment pretty much defeat the purpose.
See the discussion about SecureString (which could work in theory but only if you read a string into unmanaged memory char by char because otherwise the string would always end up in the managed heap).
The current description is quite misleading