Jansi in restricted Windows environment

[charphi]

Jansi prevents applications from running in some restricted Windows environments.
The problem is that AppLocker can forbid loading of non-signed libraries from the Windows temporary folder.

Currently, Jansi extracts a dll to the temporary folder of Windows as soon as one of its class is loaded. The method CommandLine.Help.Ansi#isJansiConsoleInstalled() triggers this behavior even if AnsiConsole.systemInstall() is not called.

One possible solution would be to add a system property that disable jansi loading such as jansi.disable with the following code:

static boolean isJansiConsoleInstalled() {
  if (Boolean.parseBoolean(System.getProperty("jansi.disable", false)) {
    return false;
  }
  ...
}

[charphi]

Erratum: I just found the org.fusesource.jansi.Ansi.disable property and I'm going to test it...

[charphi]

org.fusesource.jansi.Ansi.disable property disables ansi colors but still extracts Jansi dll.

The corrected code would be:

static boolean isJansiConsoleInstalled() {
  if (Boolean.parseBoolean(System.getProperty("org.fusesource.jansi.Ansi.disable", false)) {
    return false;
  }
  ...
}

[remkop]

Oh, very nice catch! Thank you for raising this!
I've pushed a commit with your recommended fix (slightly modified).

Can you confirm that this solves the issue?

To verify, check out picocli master locally, and build it with publishToMavenLocal. That should publish picocli-4.3.3-SNAPSHOT to your local .m2 Maven cache.

git clone https://github.com/remkop/picocli.git
cd picocli
gradlew publishToMavenLocal

You can then try this in a project that uses the info.picocli:picocli:4.3.3-SNAPSHOT dependency. Feedback very welcome!

[charphi]

It works !

But there are still two problems:

1. To use Jansi, I have to call AnsiConsole.systemInstall() with a check for the org.fusesource.jansi.Ansi.disable property. The resulting code is not complex but (needlessly ?) noisy. For example:

int exitCode = 0;
if (!Boolean.getBoolean("org.fusesource.jansi.Ansi.disable"))
  AnsiConsole.systemInstall();
try {
  CommandLine cli = new CommandLine(new MainCommand());
  cli.setCaseInsensitiveEnumValuesAllowed(true);
  exitCode = cli.execute(args);
} finally {
  if (!Boolean.getBoolean("org.fusesource.jansi.Ansi.disable"))
    AnsiConsole.systemUninstall();
  }
if (exitCode != 0) {
  System.exit(exitCode);
}

2. When executing a command that doesn't use Ansi to print help, Jansi is not needed but still triggered by AnsiConsole.systemInstall(). Therefore, the dll is extracted even if not used.

One solution that would solve both problems could be to add a new method to CommandLine that would automaticaly call AnsiConsole.systemInstall() if needed. For example:

CommandLine cli = new CommandLine(new MainCommand());
cli.setCaseInsensitiveEnumValuesAllowed(true);
cli.setInstallJansiIfNeeded();
int exitCode = cli.execute(args);

However that would require careful changes in Ansi#enabled() to get all paths right.

[remkop]

Please take a look at https://github.com/remkop/picocli-jansi-graalvm

That project was created to work around another Jansi issue, related to GraalVM native images, but I took the opportunity to add some other niceties.

We can update that to also check for Boolean.getBoolean("org.fusesource.jansi.Ansi.disable") internally. With that project, your code can look like this:

    public static void main(String[] args) {
        try (AnsiConsole ansi = AnsiConsole.windowsInstall()) { // enable colors on Windows
            new CommandLine(new MyApp()).execute(args);
        }          // Closeable does cleanup when done
    }

What do you think of this idea? If you like it, do you think you can provide a pull request to the https://github.com/remkop/picocli-jansi-graalvm project?

[remkop]

After re-reading, I was surprised by this:

When executing a command that doesn't use Ansi to print help, Jansi is not needed but still triggered by AnsiConsole.systemInstall(). Therefore, the dll is extracted even if not used.

I thought my fix would prevent the dll from being extracted if org.fusesource.jansi.Ansi.disable is set to true. Is this not happening in some cases? Which cases, can you tell me how to reproduce this?

[remkop]

Ah, sorry for the noise! The dll is extracted because the application calls AnsiConsole.systemInstall(); the method invocation may be conditional, but by that time the class is already loaded.
You would need to create another class to postpone loading until it is really needed...

[charphi]

picocli-jansi-graalvm is indeed nicer thanks to AutoCloseable and it could also handle org.fusesource.jansi.Ansi.disable property. I will create a PR about it.

---

The problem n°2 is almost a detail and only happens when all theses conditions are met:

• org.fusesource.jansi.Ansi.disable is not set to true
• no Ansi text is printed; the program just does what it is supposed to do
• AnsiConsole.systemInstall() is called in main because it could have been needed

What is missing is a mechanism that calls AnsiConsole.systemInstall() only when Ansi text is about to be printed.
It could be a callback such as commandLine.onAnsiText(AnsiConsole::systemInstall).
Or a property such as commandLine.setInstallJansiIfNeeded() that does the magic thanks to reflexion.

One attempt with picocli-jansi-graalvm could be:

public static void main(String[] args) {
        try (AnsiConsole ansi = AnsiConsole.windows()) { // enable colors on Windows
            CommandLine cmd = new CommandLine(new MyApp());
            cmd.onAnsiText(ansi::activate);
            cmd.execute(args);
        }          // Closeable does cleanup when done
    }

I have no experience with graalvm so I don't know what solution is the best.
There is also the problem that the code somehow put the focus on Jansi and Windows (by using the try-with-resources statement) instead of focusing on the command line.