On Tue, Mar 23, 2021 at 14:36:19 +0100, Michal Privoznik wrote:
On 3/22/21 5:09 PM, Tim Wiederhake wrote:
> virsh has several arguments that are better not used. This series introduces
> a formal way of marking them as deprecated.
Commit messages are rather sparse. What we currently have is hiding options
we deem obsolete from users and replacing them with better ones (just :Ggrep
VSH_OT_ALIAS). No error message, no warning. What makes these you picked
special? I'm not against reporting that an option is obsolete, but I don't
quite understand why we need a different way for obsoleting those three.
There's one exception seen in 5/5 and that is the 'base64' parameter of
'secret-set-value'. (It's not a boolean enabling base64 mode but rather
a base64 value of the secret passed on the commandline).
That option doesn't have an _ALIAS, but really shouldn't be used at all,
thus we do print a warning.
For this particular case we could consider hiding it, but it might be
problematic as it doesn't use VSH_OFLAG_REQ_OPT, so is applied without
the option name prefix [1] , which could be very misleading to users if it
were hidden from the help output.
Additionally for that particular case, printing a generic deprecation
warning wouln'd IMO be enough as it's really a security issue, not just
deprecation.
[1]:
$ virsh secret-set-value c021dc3e-8227-4bfa-8f1c-ebd0356fb872 YmxlCg==
error: Passing secret value as command-line argument is insecure!
Secret value set