subscription-manager has two ways to get secrets from users in a non-interactively way: - --password, for the password to use for an username - --token, for authentication tokens In case none is specified, sub-man will interactively ask for a password (for an username, which is the default). This approach has few downsides: - since processes can be seen by anyone, passing an explicit --password or --token is not that secure on the same machine, as visible by other users - passing things on stdin is possible, although not totally reliable (e.g. in case there are other interactive prompts, say sudo) - they cannot be statically configured anywhere The proposed approach is to combine them in a single new command line option with more flexibility: --secret SELECTOR. The format of SELECTOR is three-pieces separated by colon, i.e. "<type>:<source>:<value>" - <type> describes what is the secret: "password", "token" are the values for the current options - <source> describes what is the source of the secret: - "text" means that the the value represents the actual string of the secret, to emulate the current behaviour of --password and --token - "file" means that the value is a relative/absolute path to a text file which has a single line containing the secret - <value> contains the actual value, and depends on "source" This has few advantages: - there is a unified way to specify secrets - it is easier to add more secrets in the future without adding more command line options - it is possible to put secrets in text files (whose permissions should be strict enough to avoid unneeded readers) without compromising them - it is possible to retain the current behaviour of passing secrets inline as command line parameters - --password and --token can become aliases for --secret password:text:<password> and --secret token:text:<token> - it is possible to add more sources for secrets: a possible idea can be fd to specify a file description to read the secret from
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.