Dne 6.8.2012 16:10, Alexander Bokovoy napsal(a):
On Mon, 06 Aug 2012, Jan Cholasta wrote:
Dne 6.8.2012 15:20, Simo Sorce napsal(a):
On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

while thinking about <https://fedorahosted.org/freeipa/ticket/2933>, I
had an idea how to make loading data from files available for all

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them
(similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting
alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa AAAA ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub


(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa AAAA ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

   - data:<data> - use <data> as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
   - base64:<data> - use the value of base64 decoded <data> (useful for
--delattr on ugly raw binary values)
   - fd:<num> - read value from file descriptor <num>
   - env:<var> - read value from environment variable <var>
   - ask: - always prompt interactively for the value
   - default: - use default value, never prompt interactively


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?


You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.

I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in


I have considered this, but given that these URL-like strings would be mainly used directly by users on the command-line, I think that "base64:<stuff>" is more user friendly than "data:;base64,<stuff>".


Jan Cholasta

Freeipa-devel mailing list

Reply via email to