On Tue, 02 Jun 2015, Martin Kosek wrote:
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.
Correct, this is a part that can and should be driven by actual use
experience. Reading from the stdin is easy to implement (we have it done
for password already) so maybe we can simply reuse password option here
for such case, we even have a flag for omitting the confirmation prompt.
This is fairly small addition.
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
want...
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.
Yes, please use conditional import here, it is perfectly valid use case
for the client side.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
