On 06/02/2015 02:07 PM, Endi Sukma Dewata wrote:
> On 6/2/2015 1:10 AM, Martin Kosek wrote:
>> Hi Endi,
>> 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
Ok. Well, base64 + file input look as good enough for now. I was mostly
concerned about usability of the solution for normal users as for a manual
secret, it is not convenient to always create an interim file.
We will see based on user experience, maybe Web UI or further CLI-only
additions will be the answer.
>> 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
> 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 the future PKI might be able
Ok, makes sense. I think we will want Web UI at some point, but the summary for
FreeIPA 4.2 seems - no Web UI for Vault (yet).
>> 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.
I have major concerns here. Look at the different between installing
"freeipa-client" and "freeipa-client + pki-base" on my F21:
$ sudo yum install freeipa-client
Install 1 Package (+4 Dependent packages)
Total download size: 2.6 M
Installed size: 14 M
$ sudo yum install freeipa-client pki-base
Install 2 Packages (+288 Dependent packages)
Total download size: 160 M
Installed size: 235 M
This is obviously a no-go for client. The conditional import is smaller concern
that big dependency growth on the client. We do them in trust plugin for
example and it works fine (though I agree it is not ideal programming practice).
IMO, we should limit new freeipa-client dependencies only to
python-cryptography (or also python-nss in the worst case, in case
python-cryptography is not enough) - there should be no pki dependencies at
all, these should be only on the server side.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code