Running a script hosted in an untrusted url fails to read user choice when using `curl -sh https://sh.jbang.dev`

[mikybars]

I think the problem is quite known in any shell. If you pipe a shell script for the shell to execute it then the shell won't be able to read input from the user:

$ curl -sL https://sh.jbang.dev | bash -s -- https://github.com/mperezi/java-cli/blob/master/SendSms.java
[jbang] https://github.com/mperezi/java-cli/blob/master/SendSms.java is not from a trusted source thus not running it automatically.

If you trust the url to be safe to run you can do one of the following:
0) Trust once: Add no trust, just run this time
1) Trust this url in future:
    jbang trust add https://github.com/mperezi/java-cli/


Any other response will result in exit.

[jbang] Type in your choice (0 or 1) and hit enter. Times out after 10 seconds.
[jbang] [ERROR] Could not parse answer as a number. Aborting
[jbang] [ERROR] https://github.com/mperezi/java-cli/blob/master/SendSms.java is not from a trusted source and user did not confirm trust thus aborting.

The problem can be spotted in the following line:

[jbang] [ERROR] Could not parse answer as a number. Aborting

Do you think it would be a good idea to provide a flag --trust-once to avoid this edge cases?

[maxandersen]

$ curl -sL https://sh.jbang.dev | bash -s -- app setup && jbang https://github.com/mperezi/java-cli/blob/master/SendSms.java

Would that work?

[mikybars]

Yep that works. Not sure though if this would qualify as a "zero" install anymore 😕

[maxandersen]

Well, you can skip the setup and do ~/.jbang/bin/jbang if that helps ? :)

[quintesse]

I do think he has a point though. For most people if they use a curl command it's probably because they don't have Jbang installed. So that means that the command we show doesn't actually work for people that don't have already set the trust previously :-/

[maxandersen]

So we need to change the command shown...problem fixed ?

[mikybars]

Do you mean changing this:

$ curl -sL https://sh.jbang.dev | bash -s -- https://github.com/mperezi/java-cli/blob/master/SendSms.java

for this:

$ curl -sL https://sh.jbang.dev | bash -s -- app setup && jbang https://github.com/mperezi/java-cli/blob/master/SendSms.java

in the documentation?

I don't know. I find it a little bit... cumbersome. The former looks catchier. Besides, as I said it couldn't be advertised as zero setup anymore.

[quintesse]

I do feel the same way, it doesn't really feel as zero-install anymore that way.
In itself I'd say that any time you run a fully visible URL you are already implicitly trusting it.
Perhaps we should consider using the trust system only for those cases where you don't necessarily know what you're running (eg. aliases from remote catalogs)

[maxandersen]

There have always been a quotes around the "zero" as the sh.jbang.dev script does "install" into ~/.jbang/bin for faster second run.

I understand it is not awesome that interactive trust is not working in this case but we can't have the cake (some basic security against script runs) and eat it too ( add --trust-once)

My concern is that it becomes too easy to inject one liners in that enables everything.

What I'll do is that in 2021 I'll take it up with infosec@redhat.com and hear what their recommendations are as its past cases with them that keeps me from making it "too easy, but still okey easy" to run remote urls.

[quintesse]

I do understand your concerns, but I also think we have to compare it to the risks posed by similar systems. IMO the moment you do anything like curl xxx | sh you're putting a lot of trust in "xxx". I wonder what infosec will say about that.

[quintesse]

Not really sure if this is possible, but perhaps we should look into showing a GUI pop-up for the trust question?

[maxandersen]

We can pop up a swing gui but can't really distinguish if a console run without a working try is meant for background job or a proper terminal where a user is available to press a button.

[quintesse]

A Java app is able to detect if it was run from the console with a proper terminal, so no input redirection. We can use that, right?

[quintesse]

Well, actually, that doesn't work :-/
It least not on Linux/Mac.
It's because we use OUTPUT=$(java blah blah blah), it "disconnects"the stdin for that process from the original shell process.

A bit more rambling:
Windows uses a temporary file for that so actually in this case on Windows we would be able to detect if input was redirected or not. Which also means that we don't actually run programs in the same way on all platforms, there are some small but important differences like these that could trip us up in the future...
I wonder if we shouldn't unify the approach on all platforms, how unsatisfying it may be to use temporary files to store an app's output on Mac/Linux...

[quintesse]

Unrelated to what I just mentioned, another option to solve the original problem is to always use the GUI option unless GraphicsEnvironment.isHeadless() is true.