Problem resolved artifacts from locally run repository with self signed certificate using https

[jiramares]

Hi, we are internally using artifact repository to resolve all artifacts to have stable environment. But we have problem to realize what jvm is used to resolve artifacts (or run coursier) to import our CA certificated into it because out server uses https and its certificate is signed by our own CA certificate.

When used coursier, it look it uses it own jvm with unknown place (coursier/coursier#1977) but when run from scala-cli? (the same story or another one)?

[Gedochao]

#2191
I suspect what you're missing is -Djavax.net.ssl.trustStore=cacerts

[Gedochao]

regarding the JVM, Scala CLI will pick up the JVM defined in JAVA_HOME, and if it fulfills requirements (we require Java 17+) it'll be used.
Otherwise it will download Java 17 using coursier under the hood, so I suspect it is indeed very similar to coursier's case.

[jiramares]

Hi, thanks for your answer. It really works, but:

1. I am using Java 17 (echo $JAVA_HOME tells /opt/jdk and /opt/jdk/bin/java -version tells java version "17.0.11" 2024-04-16 LTS, the same answer gets java -version).
   In my profile I have line export COURSIER_REPOSITORIES="ivy2local|https://server/repo" (server uses self signed certificate).
   When I run scala-cli db-update.sc I got error download error: Caught javax.net.ssl.SSLHandshakeException.
   If I run scala-cli -Djavax.net.ssl.trustStore=/opt/jdk-17/lib/security/cacerts db-update.sc it works.
   So scala-cli is not using Java on PATH or specified by JAVA_HOME, maybe it is used to run the scala script but is not used to resolve dependecies.

2. I would like to run my scripts using command ./db-update.sc. Yes I can create shell alias scala-cli='scala-cli -Djavax.net.ssl.trustStore=/opt/jdk-17/lib/security/cacerts' and it works. But in my scripts I have first line #!/usr/bin/env -S scala-cli shebang and when I run ./db-update it doesn't work. The solution is not to put into every script switch -Djavax.net.ssl.trustStore=/opt/jdk-17/lib/security/cacerts because this line will be in many scripts and machine by machine the directories can be different.

[Gedochao]

Yes I can create shell alias scala-cli='scala-cli -Djavax.net.ssl.trustStore=/opt/jdk-17/lib/security/cacerts' and it works. But in my scripts I have first line #!/usr/bin/env -S scala-cli shebang and when I run ./db-update it doesn't work.

How about a simple bash script that you'd call in the shebang instead, as a workaround?
Maybe smth like:

#!/bin/bash

# Define the trustStore option
TRUST_STORE_OPTION="-Djavax.net.ssl.trustStore=/opt/jdk-17/lib/security/cacerts"

# Function to check if the trustStore option is already present
contains_trust_store_option() {
    for arg in "$@"; do
        if [[ "$arg" == "$TRUST_STORE_OPTION" ]]; then
            return 0
        fi
    done
    return 1
}

# Check if the trustStore option is present
if contains_trust_store_option "$@"; then
    # If present, call scala-cli with the arguments as-is
    exec scala-cli shebang "$@"
else
    # If not present, add the trustStore option to the arguments
    exec scala-cli shebang "$TRUST_STORE_OPTION" "$@"
fi

[Gedochao]

So scala-cli is not using Java on PATH or specified by JAVA_HOME, maybe it is used to run the scala script but is not used to resolve dependecies.

I mean, it really depends what kind of launcher you're using, I suppose... but yeah, if Java needs to be downloaded, coursier will download it in the background while running on whatever.
What's weird is that, from what I understand, you do have Java 17+ in your JAVA_HOME, but scala-cli still wants to download something. I'm thinking it might even just try to download the JVM index file to check if it's running the correct Java on your platform... Normally I'd suggest using --offline, but you really do need the CLI to access the outside world. I'm thinking the trust store option is necessary with your setup, at least for now.

[jiramares]

Hi, just to clarify. It is not downloading JDK but other dependencies (e.g. our toolkit). And I cannot force coursier to use some already installed JDK with imported self-signed server certificate in cacerts.
Using alias or other script is definitely an option I have to consider.
Thanks a lot