Feature summary (what you would like to be able to do and where):

Currently all values in envvar are masked by default regardless of their sensitivity.

The documentation states

The service is suitable for storing both configuration and secrets for your application, allowing workflows like having different config and secrets in your development/ci/production environments without changing a line of code

Having to explicitly show individually entries is relatively slow and adds unnecessary overhead for maintainers.

Using --show-values with list potentially exposes sensitive information, which may or may not be clear to the maintainer.

Being able to view all values via list that are not 'sensitive'/'secret' by default would ease troubleshooting without increasing risk.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

Given an example tool, which uses envvars as a method of (mostly) configuring the runtime, we can see there are 29 entries;

tools.cluebotng-review@tools-bastion-15:~$ toolforge envvars list
name                         value
ALLOY_REMOTE_PASSWORD        ****************
ALLOY_REMOTE_URL             ****************
ALLOY_REMOTE_USERNAME        ****************
ALLOY_SCRAPE_TARGETS         ****************
CBNG_ENABLE_IRC_MESSAGING    ****************
CBNG_ENABLE_USER_MESSAGING   ****************
CBNG_RELAY_IRC_CHANNELS      ****************
CBNG_RELAY_IRC_NICK          ****************
CBNG_RELAY_IRC_PASSWORD      ****************
DJANGO_SECRET_KEY            ****************
OAUTH_KEY                    ****************
OAUTH_SECRET                 ****************
PYTHONUNBUFFERED             ****************
REDIS_CONFIG                 ****************
REDIS_PASSWORD               ****************
TOOL_DB_HOST                 ****************
TOOL_DB_PASSWORD             ****************
TOOL_DB_SCHEMA               ****************
TOOL_DB_USER                 ****************
TOOL_DEPLOY_TOKEN            ****************
TOOL_REPLICA_PASSWORD        ****************
TOOL_REPLICA_USER            ****************
TOOL_TOOLSDB_PASSWORD        ****************
TOOL_TOOLSDB_SCHEMA          ****************
TOOL_TOOLSDB_USER            ****************
WEBSERVICE_BACKEND_HOSTNAME  ****************
WIKIPEDIA_PASSWORD           ****************
WIKIPEDIA_USERNAME           ****************

Out of these entries, only 9 are secrets that should not be widely exposed (e.g. to non-maintainers):

• ALLOY_REMOTE_PASSWORD
• CBNG_RELAY_IRC_PASSWORD
• REDIS_PASSWORD
• TOOL_DB_PASSWORD
• TOOL_REPLICA_PASSWORD
• TOOL_TOOLSDB_PASSWORD
• WIKIPEDIA_PASSWORD
• OAUTH_SECRET
• DJANGO_SECRET_KEY

Benefits (why should this be implemented?):

Having an attribute/classification associated to the entries provides the following user benefits:

• Viewing the runtime configuration has minimal overhead with the same 'safety today'
• It is clear which values are sensitive and which can be shared widely/publicly (e.g. list can be spread around)

From an infrastructure/security point of view:

• The storage layer can choose to handle sensitive entries more securely e.g. placing them in vault or using symmetric key encryption for encryption at rest
• In the case entries are compromised, there is clear feedback as to the impact (~70% reduction in the above example)
• The storage layer could track update times and implement notification/management of secrets that have not been rotated in X (increased security)
• The storage layer could outsource the actual secret storage in the form of dynamic secrets e.g. for accessing internal apis, perhaps temporary bot passwords for accessing e.g. enwiki.

These concepts do not exist today, but asserting the type of thing being stored would be the first step on the journey, otherwise it's just a key value store of unknown stuff.