pgDriver - read connection password from an environment variable

[vyraxo]

Is your feature request related to a problem? Please describe.
In the pgDriver, connection credentials are stored in plain text, which is not the best practice.

Describe the solution you'd like
I would like to read the connection's password from an environment variable. This facilitates development both locally and in a container-based environment.

Describe alternatives you've considered
I'm not aware of an alternative to read connection parameters from environment variables.

Additional context
I have an implementation of this feature and can submit a PR if this is approved. Screenshots attached.

Related issues

#1355

#857

[vyraxo]

Related PR: #1495

[dmcbride]

I like the idea of a more-secure method, but environment variables into vscode would also leak into the shells run inside vscode, maybe another idea would provide a more secure option.

For example, if we had something like ~/.config/Code/User/sqltools.json to store general ones (i.e., ones that can be accessed regardless of the workspace), and ~/.config/Code/User/sqltools.<key>.json where <key> would be a setting in the workspace, e.g., sqltools.configkey in .vscode/settings.json.

The key ideas would be:

1. Configurable per workspace when necessary
2. Not located in the workspace so it does not accidentally get into git
3. Not solely be limited to environment variables (though having it as an option is also valid).

Honestly, it would be even more cool if we could mention an external process that could spit out a json array of config objects, which could then be custom written to handle whatever the user wants - and here I'm thinking of arbitrary third-party password managers, etc., that it would be silly for sqltools to try to support directly.

[gjsjohnmurray]

Since #1084 adopted the SQLTools Driver Credentials authentication provider it has been possible to avoid storing passwords in plaintext in configuration files.

[vyraxo]

Hello @gjsjohnmurray , @dmcbride and thank you for your comments.

My use case is vscode in a containerized environment (using coder.com) and, as far as I know, environment variables are the only option to have secrets in place without any user intervention as soon as vscode is started.

The proposal in #857 (support ${env:ENV_VAR} syntax or similar) would also be a solution for my use case. I would be glad to help develop that.

If none of these approaches are suitable, let's close this feature request and my related PR in #1495

Thank you
Regards
v