On 6/2/2015 1:10 AM, Martin Kosek wrote:
Quickly skimming through your patches raised couple questions on my side:
1) Will it be possible to also store plain text password via Vault? It
talks about taking in the binary data or the text file, but will it also
work with plain user secrets (passwords)? I am talking about use like this:
# ipa vault-archive <name> --user mkosek --data Secret123
For security the plain text password should be stored in a file first:
# vi password.txt
# ipa vault-archive <name> --user mkosek --in password.txt
It's also possible to specify the password as base-64 encoded data:
# echo -n Secret123 | base64
# ipa vault-archive <name> --user mkosek --data U2VjcmV0MTIz
But it's not recommended since the data will be stored in the command
history and someone could see and decode it. I think passing a plain
text password as command line argument would be even worse. The --data
parameter is mainly used for unit testing.
Later we might be able to add an option to read from standard input:
# cat password.txt | ipa vault-archive <name> --user mkosek --std-in
2) Didn't we discuss a dependency of IPA/Vault on python-cryptography in
the past? I rather see use of python-nss for cryptography...
Yes. I might have mentioned that it would be in the 2nd (current) vault
patch. Actually it will be in the 3rd patch when we add the symmetric
and asymmetric vaults. The symmetric and asymmetric encryption will be
implemented using python-cryptography. You can also see this in an old
patch (#358) but it's obsolete now.
The standard vault in the current patch uses python-nss for transport
encryption because when the KRA interface was written
python-cryptography wasn't available on Fedora, it didn't support
certificates, and I'm not sure if it supports key wrapping.
The symmetric and asymmetric vaults add an additional layer of
encryption on top of the standard transport encryption, so it will
depend on both python-nss and python-cryptography.
In the future if the KRA can support python-cryptography without
python-nss we may be able to drop the python-nss dependency from vaults.
3) You do a lot of actions in the forward() method (as planned in
https://www.freeipa.org/page/V4/Password_Vault#Archival). But how do you
envision that this is consumed by the Web UI? It does not have access to
the forward() method. Would it need to also include some crypto library?
If Web UI wants to access vault (not sure if everybody agrees with
that), it would have to perform an encryption on the browser side. In
that case we will need to use either WebCrypto or a browser-specific
extension to implement something similar to vault_archive.forward(),
assuming the required cryptographic functionalities are available. In
4) In the vault-archive forward method, you use "pki" module. However,
this module will be only available on FreeIPA PKI-powered servers and
not on FreeIPA clients - so this will not work unless freeipa-client
gets a dependency on pki-base - which is definitely not something we
In my opinion it should be fine to require pki-base on the client
because it contains just the client library, unless you have other
concerns? Any objections to having pki-nss and pki-cryptography
dependencies on the client?
Even if we can change the client code not to depend on "pki" module,
since in this framework the client and server code are written in the
same plugin, the "import pki" still cannot be removed since it's still
needed by the server code, and I don't think conditional import is a
good programming practice.
Endi S. Dewata
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code