For importing certificates into the Java Truststore (at launch time) we currently try two things:
Edit the layer in-place.
If the layer is read-only: Copy the Truststore to the tmp dir, edit it there and provide the Truststore location to java via -Djavax.net.ssl.trustStore=...
If the tmp dir is also read-only, we skip the process silently.
This PR prints a warning to the user. It also alters the behavior to exit early, if both locations are read-only (the current implementation would continue and try to modify the the existing Truststore and ignore non-write permission problems).
Use Cases
Should help users understand what is going on.
Checklist
[x] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[x] I'm happy with the commit history on this PR (I have rebased/squashed as needed).
Summary
For importing certificates into the Java Truststore (at launch time) we currently try two things:
-Djavax.net.ssl.trustStore=...
If the tmp dir is also read-only, we skip the process silently.
This PR prints a warning to the user. It also alters the behavior to exit early, if both locations are read-only (the current implementation would continue and try to modify the the existing Truststore and ignore non-write permission problems).
Use Cases
Should help users understand what is going on.
Checklist