Embedded JDK ignores system cacerts #5741
Comments
|
Replacing the cacerts file with a symlink as a work around doesn’t work either: Also found this announcement from last April that states: Is the embedded JDK a packaging bug? |
That's from April 2017, quite a long while ago.
Could be that it's embedded unintentionally as it's not mentioned in the 0.16.0 release notes. Anyway, you might be interested in related issue #5753. |
|
@gertvdijk Indeed — on both accounts. Nevertheless the announcement declared the intent back then. I have not yet found an indicator that the intent has changed. So together with #5753 I guess it’s up for debate what route should be taken. Personally I would prefer following the Debian way (not embedding dependencies), which, of course, would also help with my requirement of using the system cacerts. |
|
This issue describes behaviour of the OpenJDK build that Bazel is using, I'm not sure there's a good fix in Bazel itself. If you don't want to use the embedded JDK, you can override it by setting a custom The issue with Repro: import java.io.*;
import java.net.*;
import javax.net.ssl.*;
public class UrlConnect {
public static void main(String[] args) {
String[] defaultArgs = {"https://git.cacert.org/cacert.git"};
if (args.length == 0) {
args = defaultArgs;
}
for (String url : args) {
try (InputStream stream = new URL(url).openStream()) {
System.out.println("OK: " + url);
} catch (SSLHandshakeException ex) {
// This is bad
System.err.println("ERROR: " + url + ": " + ex.toString());
} catch (IOException ex) {
System.out.println("Warning: " + url + ": " + ex.toString());
}
}
}
}Note that there were some changes related to cacerts starting in 9: http://www.oracle.com/technetwork/java/javase/9all-relnotes-3704433.html#JDK-8189131
|
|
@cushon Please note that I do not use
Our problem is with a private company CA. The reason this is an issue opened with Bazel is because we are using their official Debian packages and these suddenly behave differently. Before 0.16 these packages used the JDK provided by Debian which integrate with the Last but not least I understand that there are work arounds but I still have to ask the question if this is a change of the stance taken by the project or, in fact, a bug in packaging. Personally I would obviously prefer for a Debian package to not bring it’s on JDK to the party and break the nice integration features along the way. If the project however thinks that times have changed, I kindly ask it to document the change(s) and ideally also provide work arounds for such issues as part of the official documentation. You may ask why I don’t just use the work around and be done with it? Since it means hard coding a path in several locations instead of using an “automagic” solution managed by the distribution. Who knows what other stuff will break down the line because our setup is suddenly “non-standard”? Thank you for linking the Google Groups discussion, matthew indeed has the same issue. |
Rest assured that the Bazel team feels the same. This will be a temporary measure. Java has recently switched to a six month release schedule and we found that many older but still popular distributions don't ship with a sufficiently recent JDK that we decided to go the embedded way for now. |
|
@buchgr It’s of course nice to hear that the Bazel shares that sentiment but now I’m confused as to what happens next. Even if it is a “temporary measure” it still means it breaks this integration “for now”. Also I would assume that there always will be popular distributions with outdated dependencies. Or is one of the ideas to have separate repositories per distribution? |
RHEL / CentOS, Debian stable, Ubuntu LTS, ... will probably always ship way too outdated JDKs for our needs. It's not like this will change in the future. The idea of using an embedded JDK was to become independent of what JDK versions the popular distributions ship and not break our users when we upgrade to a newer one. Of course we can ask people who use these distros to just install a suitable JDK via their package manager, even if it means getting it from some PPA or third-party repository, but is that better? When we discussed this ~2 years (?) ago, the sentiment was: "No, requiring people to install system packages from third-party repos just to use Bazel is not acceptable". I personally think that embedding a JDK in our official releases and distro packages is the right thing to do, as this is the only way to ensure that people use what we actually tested on CI and also use ourselves. We had breakages with JavaBuilder in the past even when people used the correct major version of OpenJDK, but a too new or too old patch version that we didn't test against. For packages maintained by distributions themselves (this also applies to Homebrew), they would obviously feel different, but then they'd be responsible for picking matching versions of the JDK and Bazel in their overall version ecosystem and testing the results - just as they already successfully do with all other packages they maintain. |
This is just historical baggage - we had a special jdk1.7 build that used an older, fixed version of JavaBuilder for a while, but when Bazel finally broke compatibility and just could no longer build / run with that version, we dropped it. We just kept the remaining jdk1.8 component. |
That's what we are doing today. See https://docs.bazel.build/versions/master/install-ubuntu.html#using-bazel-custom-apt-repository
That's a problem and I think you are also aware that we have agreed that going forward we need to be able to supply the correct JavaBuilder for all supported major JDK versions. You additionally also know that we will soon hide the embedded JDK from the |
|
@buchgr Why do you think do we even have an embedded JDK, if asking people to simply install the correct one is fine? (No snark intended, honest question.) |
|
For the target For We've been discussing using a remote repository for the default |
|
For everyone coming here using Google/search hoping to see a work-around posted, here is one for Debian/Ubuntu and derivatives: Put in your bazelrc file these two startup options: From earlier comment:
|
|
@gertvdijk: With Bazel 0.16.1 this fails with INFO: Reading 'startup' options from /path/to/workspace/.bazelrc: --host_jvm_args=-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cac
erts --host_jvm_args=-Djavax.net.ssl.trustStorePassword=changeit
Server crashed during startup. Now printing /home/ccoalson/.cache/bazel/_bazel_ccoalson/f8087e59fd95af1ae29e8fcb7ff1a3
dc/server/jvm.out
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by io.netty.util.internal.ReflectionUtil (file:/home/ccoalson/.cache/bazel/_bazel_ccoalson/install/ca1b8b7c3e5200be14b7f27896826862/_embedded_binaries/A-server.jar) to field sun.nio.ch.SelectorImpl.selectedKeys
WARNING: Please consider reporting this to the maintainers of io.netty.util.internal.ReflectionUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release |
This indicates something is hopelessly wrong. Some things to check:
|
aiuto
added
team-Bazel
… due to the embedded JDK. From: bazelbuild/bazel#5741
dslomov
added
team-OSS
philwo
added
P2
|
Same issue. Any update? |
Please be more specific on your system/environment. I've been using the approach I commented earlier for a year now. Are you able to apply a work-around like that? (probably needs adjustments to your system if not Debian/Ubuntu-like.) |
|
@gertvdijk Oh, why didn't I see that?! |
|
On a Mac, I've installed my root cert to my jvm certs file, for me it's: I can verify my expected cert is in that file with: In my ~/.bazelrc file, I have: When I run my So It's parsing the file, and doesn't seem to complain about it. However, it fails to install any packages while I'm on my company's corporate VPN (which is what inserts this cert):
Any thoughts here? |
|
Hi @AndrewRayCode, unfortunately I don't know much about how Java handles SSL certificates, but I just had an idea. You could try to run Bazel with your system JDK and see if that makes it work: |
|
I ran into this on macOS. After installing |
|
Dominik's response unfortunately did not work for me, but adding |
Description of the problem / feature request:
Before Bazel 0.16 at least the Debian packages depended on the system jdk.
Bazel 0.16 apparently embeds the JDK which fundamentally changes the behaviour at least in regards to cacerts. The custom CA certificates that have been added to the system certificate store are of course missing in the embedded JDK’s cacerts:
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Set up a Vagrant box with Debian Stretch and install Bazel 0.16 from the APT repository (
http://storage.googleapis.com/bazel-apt stable jdk1.8). Also install the CACert root CAapt install ca-certificates cd /usr/local/share/ca-certificates wget http://www.cacert.org/certs/root.crt update-ca-certificatesIn a folder of your choosing, create
and
Note: This has nothing to do with CACert but they are the only public site I know that uses a certificate from CA that’s not in most default certificate bundles.
Now try to “build” the package.
If you use Bazel 0.15 instead the error message will be different:
Note: If the CACert CA is not installed in the system the error message will be the same as with 0.16.
What operating system are you running Bazel on?
Debian 8 Stretch
What's the output of
bazel info release?What's the output of
git remote get-url origin ; git rev-parse master ; git rev-parse HEAD?N/A
Have you found anything relevant by searching the web?
!3915 tells me how to override the path to cacerts but it would be better if Bazel just uses the system’s cacerts instead. Personally I think this is a regression breaking backwards compatibility.
Any other information, logs, or outputs that you want to share?
0.16 definitely brings its own cacerts while 0.15 does not even have the jdk folder.
The text was updated successfully, but these errors were encountered: