Quarkus CLI fails to work with encryption keys starting with "-q"

[mocenas]

Describe the bug

Using quarkus CLI to encrypt config fails, when manually specifying encryption key, starting with "-q". Like:

$: quarkus config encrypt --key=-qwi5grDHLU05KegUhfNNeA  "Joe Biden"
[ERROR] ❗  Expected parameter for option '--key' but found '-qwi5grDHLU05KegUhfNNeA'

This doesn't happen if I change either dash or "q" to anything else.

Also this "unusable" key was automatically generated using quarkus config encrypt whatever. CLI printed out
The secret whatever was encrypted to ... with the generated encryption key (base64): -qwi5grDHLU05KegUhfNNeA.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

Quarkus cli 3.14.4

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @ebullient (cli), @maxandersen (cli)

[ebullient]

Does that happen if you quote the value?

[mocenas]

Does that happen if you quote the value?

Yes it does:

$: quarkus config encrypt --key="-qwi5grDHLU05KegUhfNNeA"  "Joe Biden"
[ERROR] ❗  Expected parameter for option '--key' but found '-qwi5grDHLU05KegUhfNNeA'

$: quarkus config encrypt "--key=-qwi5grDHLU05KegUhfNNeA"  "Joe Biden"
[ERROR] ❗  Expected parameter for option '--key' but found '-qwi5grDHLU05KegUhfNNeA'

[maxandersen]

Which os/shell are you using ?

[mocenas]

Which os/shell are you using ?

linux/bash

[radcortez]

This seems to be an issue with picocli itself:

@CommandLine.Command(name = "dashed")
public class DashedOption implements Callable<Integer> {
    @CommandLine.Option(names = "-x")
    String x;

    @CommandLine.Option(names = "--required", required = true)
    String required;

    @Override
    public Integer call() throws IOException {
        return 0;
    }

    public static void main(String[] args) {
        new CommandLine(new DashedOption()).execute(new String[]{"--required=-1"});
        new CommandLine(new DashedOption()).execute(new String[]{"--required=-"});
        new CommandLine(new DashedOption()).execute(new String[]{"--required=-a"});
        new CommandLine(new DashedOption()).execute(new String[]{"--required=-x"});
    }
}

Output:

Expected parameter for option '--required' but found '-x'
Usage: dashed --required=<required> [-x=<x>]
      --required=<required>

  -x=<x>

When one option value starts with another option it causes the issue. In the quarkus config case it is the -q option for quiet mode. It works as expected if we try the same command, with -dwi5grDHLU05KegUhfNNeA.

@mocenas Would you mind opening an issue in https://github.com/remkop/picocli? I can do it, but since you found the issue, you may want to report it :)

[mocenas]

@mocenas Would you mind opening an issue in https://github.com/remkop/picocli? I can do it, but since you found the issue, you may want to report it :)

@radcortez - Can you handle this picocli issue? IMHO it should be handled by someone who has deeper technical knowledge of this, that I do.

[radcortez]

Sure.

BTW, this of course happens with other CLI commands from Quarkus:

🌀 quarkus create app -x=-e
[ERROR] ❗  Expected parameter for option '--extensions' but found '-e'

Usage: quarkus create app [-Beh] [--dry-run] [--refresh] [--[no-]
                          registry-client] [--verbose] [--config=CONFIG]
                          [--description=DESCRIPTION] [--name=NAME]
                          [-o=OUTPUT-DIR] [-D=<String=String>]...
                          [--data=<String=String>]... [-x=EXTENSION[,
                          EXTENSION...]]... [-P=groupId:artifactId:version |
                          -S=platformKey:streamId] [--jbang | --maven |
                          --gradle | --gradle-kotlin-dsl]
                          [[--java=<javaVersion>] [--kotlin] [--scala]] [[--
                          [no-]wrapper] [--[no-]code] [--[no-]dockerfiles]
                          [--package-name=PACKAGE-NAME] [-c=<appConfig>]]
                          [[GROUP-ID:]ARTIFACT-ID[:VERSION]]

See 'quarkus create app --help' for more information.

With another dashed value, but not for an option:

🌀 quarkus create app -x=-a
[ERROR] ❗  Multiple extensions matching '-a'
     - io.quarkus:quarkus-agroal
     - io.quarkus:quarkus-amazon-lambda-http
     - io.quarkus:quarkus-amazon-lambda-rest
     - io.quarkus:quarkus-amazon-lambda-xray

[radcortez]

remkop/picocli#2340

[radcortez]

We could prevent that behaviour with https://picocli.info/#_enable_consuming_option_names_or_subcommands

On the other hand, it may be dangerous due to:

If an option is defined as arity = "*", this option will consume all remaining command line arguments following this option (until the End-of-options delimiter) as parameters of this option.

The correct way to do it right now is to use quotes with escapes:

quarkus config encrypt --key=\"-qwi5grDHLU05KegUhfNNeA\" "Joe Biden"

@ebullient what do you think?

[ebullient]

Messy, but I think correct if clearly documented. I don't know how often a value followed by a dash is.

We could also (specifically for the encryption key) test out picocli's support for passwords, where you are prompted for the option if you don't specify it.

https://picocli.info/#_interactive_password_options

[radcortez]

Messy, but I think correct if clearly documented. I don't know how often a value followed by a dash is.

Not very often I guess. Encryption keys are generated. I've just generated a few thousand, and I didn't get any that would reproduce the issue, but it can happen.

We could also (specifically for the encryption key) test out picocli's support for passwords, where you are prompted for the option if you don't specify it.

I guess we can add it, but it won't eliminate the option to set it in the command directly.

[ebullient]

Yea.. my thinking is.. either people escape the quotes (because docs mention it), or they use the interactive option so the password isn't in your command history at all (which also avoids the leading dash interpretation problem)

[maxandersen]

If quotes work we go with that.

[radcortez]

Ok, so in that case, we can close this issue with the resolution to https://picocli.info/#_option_names_or_subcommands_as_option_values and use "\ to escape the value.