> Le 30/09/2017 à 17:09, Thorsten Glaser a écrit : > >> IMHO consistency within Debian is *much* more important. >> >> I would be seriously fucked off if I could connect to a host >> using something like wget but not a Java™ application, after >> installing the custom CA into /etc/ssl/certs or similar, or >> even with the defaults. > > Similarly I would be seriously fucked off if the application I developed > on another OS would behave differently once deployed on my Debian server > with the same version of Java ;)
I wholeheartedly disagree with that statement if the only reason the application behaves different are the system's root CAs. This is one of the areas where I consider Java to be seriously broken. There is absolutely no reason for a programming framework to decide which CAs it trusts or not; the operating system has means to provide the trusted CAs (files on Debian, APIs on Windows/Mac). The operating system or supporting tools also have the means to manage the trusted CAs, for the entire system (e.g. with Puppet and friends, Group Policies, MDM profiles). > Both use cases are valid I think, maybe we could have it both ways with > something like this: > 1. Let the openjdk package build and install its own cacerts file. > 2. ca-certificates-java still generates a keystore from the Debian > certificates but with a different name (cacerts-debian for example). > 3. Patch openjdk to use cacerts-debian in priority if it exists, and > default to cacerts otherwise. > 4. Downgrade ca-certificates-java to a suggested or recommended > dependency of openjdk-*-jre-headless Such a change would most likely break many existing setups. I also could not find a definitive list of OpenJDK supported CAs, and from what I can tell Oracle's JRE/JDK still trusts the Symantec and WoSign/StartCom certificates. > This way ca-certificates-java becomes optional, and installing it forces > the JRE to use the Debian certificates. This would also get rid of the > circular dependency. > > Emmanuel Bourg Ingo