Passing any secrets over the command line is insecure as anyone on the host can find out the command line args by doing ps axx.  We should allow the activation key to be specified via a file.

We currently also allow the rhsm password to be passed in via a file. We want to combine the rhsm password with this into a single config file and deprecate the --password-file option

The rhsm password file is defined in toolopts.py.  You can look into it for information on what is currently being done:

• https://github.com/oamg/convert2rhel/blob/v0.25/convert2rhel/toolopts.py#L32
• https://github.com/oamg/convert2rhel/blob/v0.25/convert2rhel/toolopts.py#L156
• https://github.com/oamg/convert2rhel/blob/v0.25/convert2rhel/toolopts.py#L281

Steps to take:

• Look for a config file from several locations:
  • /etc/convert2rhel.ini
  • ~/.convert2rhel.ini
  • (Command line parameter.  See below)
• Parse the config files and set the options.
  • The precedence order should be: command line config file if specified, then home dir, then /etc/. (ie: a config file specified on the command line overrides anything in the home dir which overrides anything in the /etc/ file).
  • Initially, options should mirror the command line options that need to be kept secret (and so should not be given on the command line)
    • password
    • activation-key

• Merge the config file settings with the command line settings
  • Command line options take precedence over the config file.
  • One cornercase: If the user specifies a password on the command line and an activation key in the config file, we need a mechanism for the subscription code to decide that the password takes precedence over the activation-key (otherwise the activation key will be used in preference to the password)
    • Idea 1: When we merge the command line entries with the config file entries, if a password is specified on the command line, delete the activation key.
      • Con: if we ever change our policies (for instance, first try the activation-key, if that fails, try the username and password), we would have to remember that the activation-key from the config file is being removed in this code, far away from its usage.
      • After talking with Michal and Eric, this is the option we would like to implement
    • Idea 2: make the user explicitly specify a command line option to disable the activation-key specified in the config file
      • Con: It is a bit unintuitive forcing the user to specify it will lead them to question why we can't autodetect the situation.
    • Idea 3: Our data structure holding the options (ToolOpts) also holds information about where the option came from.  The subscription code can then decide to use the password from the command line in preference to the activation-key from the config file
      • Con: Any code using these values will have to make a policy decision about whether and when to prefer activation-key vs rhsm password.
• Add a command line parameter to specify alternate config file locations
  • (--config-file, -c)  with one argument, the config file path.
• If the user specified (--password-from-file, -f), log a deprecation warning that --password-file is deprecated and to use the config file instead