Password is encrypted in a database and decrypted when the configuration script is rendered. We need to store the password in a decryptable way so that we can transfer it to the machine where virt-who will be deployed. On that target machine, the password is then encrypted using virt-who's master password.

That's why we recommend using trusted channel while transfering the configuration script, best way is to use hammer, it uses https to access Satellite. But since some users don't install hammer on target machines, we also provide the configuration script in UI for "ctrl+c;ctrl+v" approach and there we need to display the password.

Is there a suggestion how to change to workflow?

Looking at the customer case, customer says "the issue is that the password is stored in plain text within the satellite server itself." which is not true. We just decrypt that on demand. So I'd suggest closing as not a bug.

Hello,

The customer replied:

"ok it is stored encrypted. 

For us, displaying the Password in Plaintext is still an issue,  because the user for the hypervisor-access has broad credentials in the company. We do have a lot of satellite admins which not all should be able to know the password of that user. If, from your point of view, this is a "won't fix" problem, then you can close the call. We will continue to not use the gui-configuration for virt-who."


let me know if you still feel that this cannot be considered as an issue.

Is there a recommendation from customer how to resolve this? We could drop the script (ctrl+c,ctrl+v) deployment mode and only support hammer from now on if that helps. Or we could made it hidden only but the password would be still in clipboard after user copies the value.

Feedback from the customer:

could you add the option to directly feed the virt-who generated hash string itself to the sat6 webui instead of the plaintext password?
then the deployment script wouldn't require the plaintext password to generate the hash itself.

> could you add the option to directly feed the virt-who generated hash string itself to the sat6 webui instead of the plaintext password?
then the deployment script wouldn't require the plaintext password to generate the hash itself.

We can't, virt-who uses master password which is always specific to host where you deploy it. We can't create the hash (or more precisely encrypt it) on Satellite side, since we don't know that master password. Note that we can't hash it, since virt-who needs to be able to decrypt the original value in order to be able to communicate with the compute resource.

The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

*** Bug 2116590 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 2158702 ***