> 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
