Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #10046 > unrolled thread

Re: ca-certificates-java_20170930_source.changes ACCEPTED into unstable

Started byEmmanuel Bourg <ebourg@apache.org>
First post2017-09-30 16:20 +0200
Last post2017-10-13 00:20 +0200
Articles 9 — 5 participants

Back to article view | Back to linux.debian.maint.java

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ca-certificates-java_20170930_source.changes ACCEPTED into  unstable Emmanuel Bourg <ebourg@apache.org> - 2017-09-30 16:20 +0200
    Re: ca-certificates-java_20170930_source.changes ACCEPTED into  unstable Thorsten Glaser <t.glaser@tarent.de> - 2017-09-30 17:10 +0200
      RE: ca-certificates-java changes "Ingo Bauersachs" <ingo@jitsi.org> - 2017-10-13 00:40 +0200
      Re: ca-certificates-java changes Emmanuel Bourg <ebourg@apache.org> - 2017-10-13 00:40 +0200
      Re: ca-certificates-java changes Emmanuel Bourg <ebourg@apache.org> - 2017-10-13 01:00 +0200
        Re: ca-certificates-java changes Thorsten Glaser <t.glaser@tarent.de> - 2017-10-13 01:20 +0200
    Re: ca-certificates-java_20170930_source.changes ACCEPTED into  unstable Matthias Klose <doko@debian.org> - 2017-09-30 20:30 +0200
    Re: ca-certificates-java_20170930_source.changes ACCEPTED into unstable Tiago Daitx <tiago.daitx@canonical.com> - 2017-10-02 23:20 +0200
      Re: ca-certificates-java_20170930_source.changes ACCEPTED into  unstable Emmanuel Bourg <ebourg@apache.org> - 2017-10-13 00:20 +0200

#10046 — Re: ca-certificates-java_20170930_source.changes ACCEPTED into unstable

FromEmmanuel Bourg <ebourg@apache.org>
Date2017-09-30 16:20 +0200
SubjectRe: ca-certificates-java_20170930_source.changes ACCEPTED into unstable
Message-ID<uvqMx-5eq-7@gated-at.bofh.it>
Hi Matthias,

Le 30/09/2017 à 02:35, Debian FTP Masters a écrit :

>      - Stop fiddling around with jvm-*.cfg files. ca-certificates-java
>        has no business with providing an initial cacerts file. This is
>        implemented in the openjdk packages. We are not 2008 anymore.

Are you suggesting that we should drop ca-certificates-java and just
rely on the root certificates from OpenJDK instead? I would welcome this
simplification, the certificates in OpenJDK are frequently updated
anyway, and that would improve the consistency with the Oracle JDK.

Emmanuel Bourg

[toc] | [next] | [standalone]

#10047

FromThorsten Glaser <t.glaser@tarent.de>
Date2017-09-30 17:10 +0200
Message-ID<uvryV-5MV-7@gated-at.bofh.it>
In reply to#10046
On Sat, 30 Sep 2017, Emmanuel Bourg wrote:

> Are you suggesting that we should drop ca-certificates-java and just
> rely on the root certificates from OpenJDK instead? I would welcome this
> simplification, the certificates in OpenJDK are frequently updated
> anyway, and that would improve the consistency with the Oracle JDK.

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.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

[toc] | [prev] | [next] | [standalone]

#10073 — RE: ca-certificates-java changes

From"Ingo Bauersachs" <ingo@jitsi.org>
Date2017-10-13 00:40 +0200
SubjectRE: ca-certificates-java changes
Message-ID<uzUj2-3ov-71@gated-at.bofh.it>
In reply to#10047
> 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

[toc] | [prev] | [next] | [standalone]

#10076 — Re: ca-certificates-java changes

FromEmmanuel Bourg <ebourg@apache.org>
Date2017-10-13 00:40 +0200
SubjectRe: ca-certificates-java changes
Message-ID<uzUjb-3ov-275@gated-at.bofh.it>
In reply to#10047
Le 12/10/2017 à 11:58, Emmanuel Bourg a écrit :

> 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.

Another thought: maybe we could use a symlink managed by the
alternatives system instead of patching OpenJDK to look for
cacerts-debian. This would be even better since some Java applications
may open cacerts directly from its path, and since they are unlikely to
know about cacerts-debian they would load the wrong keystore.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10081 — Re: ca-certificates-java changes

FromEmmanuel Bourg <ebourg@apache.org>
Date2017-10-13 01:00 +0200
SubjectRe: ca-certificates-java changes
Message-ID<uzUj3-3ov-73@gated-at.bofh.it>
In reply to#10047
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 ;)

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

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

[toc] | [prev] | [next] | [standalone]

#10084 — Re: ca-certificates-java changes

FromThorsten Glaser <t.glaser@tarent.de>
Date2017-10-13 01:20 +0200
SubjectRe: ca-certificates-java changes
Message-ID<uzUVM-4id-95@gated-at.bofh.it>
In reply to#10081
Hi Emmanuel,

> 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 ;)
> 
> Both use cases are valid I think, maybe we could have it both ways with

with an upstream hat on, this is a valid concern. But with
a DD hat on, integration *within* the distribution *is* the
primary goal… after all, that’s the very *job* of the distro.

Perhaps OpenJDK could ship the upstream-provided keystore,
but in the presence of a Debian one, it must take precedence
(perhaps with debconf or by making ca-certificates-java into
only a Recommends or whatever).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

[toc] | [prev] | [next] | [standalone]

#10048

FromMatthias Klose <doko@debian.org>
Date2017-09-30 20:30 +0200
Message-ID<uvuGt-7KB-9@gated-at.bofh.it>
In reply to#10046
On 30.09.2017 16:18, Emmanuel Bourg wrote:
> Hi Matthias,
> 
> Le 30/09/2017 à 02:35, Debian FTP Masters a écrit :
> 
>>      - Stop fiddling around with jvm-*.cfg files. ca-certificates-java
>>        has no business with providing an initial cacerts file. This is
>>        implemented in the openjdk packages. We are not 2008 anymore.
> 
> Are you suggesting that we should drop ca-certificates-java and just
> rely on the root certificates from OpenJDK instead? I would welcome this
> simplification, the certificates in OpenJDK are frequently updated
> anyway, and that would improve the consistency with the Oracle JDK.

No. Why should we?

[toc] | [prev] | [next] | [standalone]

#10052 — Re: ca-certificates-java_20170930_source.changes ACCEPTED into unstable

FromTiago Daitx <tiago.daitx@canonical.com>
Date2017-10-02 23:20 +0200
SubjectRe: ca-certificates-java_20170930_source.changes ACCEPTED into unstable
Message-ID<uwgi8-Zh-53@gated-at.bofh.it>
In reply to#10046
On Sat, Sep 30, 2017 at 10:18 AM, Emmanuel Bourg <ebourg@apache.org> wrote:
> Hi Matthias,
>
> Le 30/09/2017 à 02:35, Debian FTP Masters a écrit :
>
>>      - Stop fiddling around with jvm-*.cfg files. ca-certificates-java
>>        has no business with providing an initial cacerts file. This is
>>        implemented in the openjdk packages. We are not 2008 anymore.
>
> Are you suggesting that we should drop ca-certificates-java and just
> rely on the root certificates from OpenJDK instead? I would welcome this
> simplification, the certificates in OpenJDK are frequently updated
> anyway, and that would improve the consistency with the Oracle JDK.

This change simply dropped the logic where the postinst script tried
to detect a jvm.cfg in /etc/<jvm> and then created one in case it
wasn't there. This is no longer required because OpenJDK was patched
back in 2008 [1] to look for a "jvm.cfg-default" file that we ship
with the package and is in a good and known state. The fact that
ca-certificates-java failed just now is because of the introduction of
aarch32 which does not have a C2 compiler (ie. server) as expected by
the temporary jvm.cfg setup it uses.

This was never a suggestion to actually drop the package.


To give an overview of the issue, this happens during install time
when both openjdk and ca-certificates are being installed because
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jvm.cfg is a symlink
to /etc/java-8-openjdk/jvm-amd64.cfg (on amd64) which does not exist
until the openjdk package is configured. The patched openjdk looks
instead for the other default jvm.cfg that we ship exactly for this
reason.

$ ls -l /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jvm.cfg*
lrwxrwxrwx 1 root root  33 Aug 23 15:41
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jvm.cfg ->
/etc/java-8-openjdk/jvm-amd64.cfg
-rw-r--r-- 1 root root 278 Aug 23 15:41
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jvm.cfg-default


[1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/revision/315

Regards,
Tiago

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.daitx@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

[toc] | [prev] | [next] | [standalone]

#10071

FromEmmanuel Bourg <ebourg@apache.org>
Date2017-10-13 00:20 +0200
Message-ID<uzTZQ-34a-367@gated-at.bofh.it>
In reply to#10052
Le 2/10/2017 à 23:16, Tiago Daitx a écrit :

> To give an overview of the issue, this happens during install time
> when both openjdk and ca-certificates are being installed because
> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jvm.cfg is a symlink
> to /etc/java-8-openjdk/jvm-amd64.cfg (on amd64) which does not exist
> until the openjdk package is configured. The patched openjdk looks
> instead for the other default jvm.cfg that we ship exactly for this
> reason.

Hi Tiago,

Thanks a lot for the detailed explanation, this is much clearer now.

Emmanuel Bourg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web