Package: default-jre-headless
Version: 2:1.11-71
Depends: openjdk-11-jre-headless, java-common

Package: openjdk-11-jre-headless
Version: 11.0.3+1-1
Depends: ca-certificates-java, ...
Provides: java-runtime-headless, java10-runtime-headless, java11-runtime-headless, java2-runtime-headless, java5-runtime-headless, java6-runtime-headless, java7-runtime-headless, java8-runtime-headless, java9-runtime-headless

Package: ca-certificates-java
Version: 20190405
Depends: ca-certificates (>= 20121114), default-jre-headless | java8-runtime-headless, libnss3 (>= 3.12.10-2~)


Dependency cycles need to be broken by apt/dpkg to configure the
packages. This splitting can be done the wrong way ...
There is at least one piuparts test failing a stetch->buster upgrade
because packages get configured in the wrong order:

...
  Setting up ca-certificates-java (20190405) ...
...
  Setting up default-jre-headless (2:1.11-71) ...
...
  Setting up jython (2.7.1+repack1-3) ...
...
  Setting up jython-stilts (3.1.5-1) ...
  Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
  	at org.python.core.io.BufferedReader.clear(BufferedReader.java:147)
  	at org.python.core.io.BufferedReader.<init>(BufferedReader.java:27)
  	at org.python.core.PyFile.createBuffer(PyFile.java:227)
  	at org.python.core.PyFile.file___init__(PyFile.java:185)
  	at org.python.core.PyFile.file___init__(PyFile.java:178)
  	at org.python.core.PyFile.<init>(PyFile.java:101)
  	at org.python.core.PySystemState.<init>(PySystemState.java:237)
  	at org.python.core.PySystemState.doInitialize(PySystemState.java:1112)
  	at org.python.core.PySystemState.initialize(PySystemState.java:1023)
  	at org.python.core.PySystemState.initialize(PySystemState.java:979)
  	at org.python.core.PySystemState.initialize(PySystemState.java:974)
  	at org.python.util.jython.run(jython.java:263)
  	at org.python.util.jython.main(jython.java:142)
  dpkg: error processing package jython-stilts (--configure):
   installed jython-stilts package post-installation script subprocess returned error exit status 1
...
  Setting up openjdk-11-jre-headless:amd64 (11.0.3+1-1) ...
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/rmid to provide /usr/bin/rmid (rmid) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/java to provide /usr/bin/java (java) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/keytool to provide /usr/bin/keytool (keytool) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/jjs to provide /usr/bin/jjs (jjs) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/pack200 to provide /usr/bin/pack200 (pack200) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode
  update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
  update-binfmts: warning: current package is openjdk-11, but binary format already installed by openjdk-8
...

Package: jython-stilts
Depends: jython, ...

Package: jython
Depends: ..., default-jre-headless (>= 2:1.9) | java9-runtime-headless


At the time jython-stilts gets configured, /usr/bin/java is still from
openjdk-8, despite of default-jre-headless 2:1.11 being configured and thus
promising a never java to be available, satisfying the dependency in jython.


The failing piuparts test was run on amd64 with these extra arguments:
  --install-recommends --upgrade-before-dist-upgrade


Andreas

Hi,

I looked into this again and would suggest to demote the
  ca-certificates-java -> default-jre-headless
dependency to a recommends.
ca-certificates-java will have to gracefully handle the case that no JRE
is available at all and that one becomes available later.

No package in the archive depends on ca-certificates-java and expects to
get a JRE that way.
This does not change anything for packages depending on
default-jre-headless or openjdk-11-jre-headless or an installation of
ca-certificates-java with --install-recommends enabled (default),
just the order of configuration gets more deterministic.

The interesting case is installation of ca-certificates-java without
recommends if no jre is installed, and a subsequent installation of a
jre-headless package.
I solved this via triggers on /usr/lib/jvm which are propagated to the
update-ca-certificates trigger.

This does not seem to work entirely as I wanted, since
/etc/ssl/certs/java/cacerts does not get populated in this case, but I'm
not sure how the hook script is supposed to work:
* if I manually delete /etc/ssl/certs/java/cacerts and
  dpkg-reconfigure ca-certificates afterwards to run the hook scripts,
  only a 32-byte large file is created
* if I install ca-certificates-java in stretch and thereafter upgrade
  ca-certificates to the buster version, ca-certificates reports some
  added and some revoved certificates, but running the hook script does
  not seem to update /etc/ssl/certs/java/cacerts either.

Please see the attached patch that implements this in
ca-certificates-java, I verified that the problemetic upgrade path is
fixed with this updated package.

I also fixed some issues (mostly inconsistencies w.r.t. supported java
versions) I noticed while developing this patch.


Andreas

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
     - I was installing default-jre/jdk on my 32-bit ARM machine and it refused to install
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
     - sudo apt install default-jre
   * What was the outcome of this action?
     Setting up ca-certificates-java (20190405) ...
     head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or directory
     Adding debian:ISRG_Root_X1.pem
     Adding debian:EC-ACC.pem
     Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
     Adding debian:thawte_Primary_Root_CA.pem
     Adding debian:GeoTrust_Universal_CA_2.pem
     Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem
     Adding debian:thawte_Primary_Root_CA_-_G2.pem
     Adding debian:Sonera_Class_2_Root_CA.pem
     Adding debian:IdenTrust_Commercial_Root_CA_1.pem
     Adding debian:SSL.com_Root_Certification_Authority_RSA.pem
     Adding debian:ePKI_Root_Certification_Authority.pem
     Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
     #
     # A fatal error has been detected by the Java Runtime Environment:
     #
     #  SIGILL (0x4) at pc=0xb40da688, pid=2392, tid=2398
     #
     # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10-post-Debian-3deb10u1)
     # Java VM: OpenJDK Server VM (11.0.7+10-post-Debian-3deb10u1, mixed mode, serial gc, linux-)
     # Problematic frame:
     # J 46% c2 sun.security.provider.X509Factory.readOneBlock(Ljava/io/InputStream;)[B java.base@11.0.7 (447 bytes) @ 0xb40da688 [0xb40da440+0x00000248]
     #
     # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
     #
     # An error report file with more information is saved as:
     # //hs_err_pid2392.log
     Could not load hsdis-arm.so; library not loadable; PrintAssembly is disabled
     #
     # If you would like to submit a bug report, please visit:
     #   https://bugs.debian.org/openjdk-11
     #
     /var/lib/dpkg/info/ca-certificates-java.postinst: line 88:  2390 Done        find /etc/ssl/certs -name \*.pem
     2391                       | while read filename; do
     alias=$(basename $filename .pem | tr A-Z a-z | tr -cs a-z0-9 _); alias=${alias%*_}; if [ -n "$FIXOLD" ]; then
     echo "-${alias}"; echo "-${alias}_pem";
     fi; echo "+${filename}";
     done
     2392 Aborted                 | java -Xmx64m -jar $JAR -storepass "$storepass"
     dpkg: error processing package ca-certificates-java (--configure):
     installed ca-certificates-java package post-installation script subprocess returned error exit status 134
     Processing triggers for fontconfig (2.13.1-2) ...
     Processing triggers for mime-support (3.62) ...
     Processing triggers for hicolor-icon-theme (0.17-2) ...
     Processing triggers for libc-bin (2.28-10) ...
     Processing triggers for man-db (2.8.5-2) ...
     Processing triggers for ca-certificates (20190110) ...
     Updating certificates in /etc/ssl/certs...
     0 added, 0 removed; done.
     Running hooks in /etc/ca-certificates/update.d...

     done.
     done.
     Errors were encountered while processing:
     ca-certificates-java
     E: Sub-process /usr/bin/dpkg returned an error code (1)
     * What outcome did you expect instead?

     *** End of the template - remove these template lines ***

Hi all,

Any objections to the patch of Andreas? If not, I propose to proceed to
fix this issue now, and still have some time before the bullseye release
to fix corner case issues caused by the fix.

Paul

Hi

To fix this cycle, which makes any package dependency on
default-jre-headless unstable, I propose to change the dependency in
ca-certificates-java to just specify openjdk-11-jre-headless, without
any default-jre-headless alternative.

Yes, this will cause the default java version to be installed, but this
seems way better then all the alternatives.

Yes, this does not fix the cycle between java and ca-certificates-java,
but at least it breaks less.

Regards,
Bastian

Tianon pointed to

p11-kit's "trust extract --format=java-cacerts ..." works pretty well in my
experience (that's how Alpine Linux solves this particular problem:
https://gitlab.alpinelinux.org/alpine/aports/-/blob/bd4e89c6a26bf7c247c3335b8a7aef053815dfc7/community/java-cacerts/APKBUILD#L18-19)
(and how I've done so on systems where I didn't want to install
ca-certificates-java for one reason or another)

Using p11-kit to avoid the circular dependency sounds nice.  Bastian's
suggestion is not ideal, but works for me as well.

I committed Andreas' proposed changes to ca-certificates-java, however that
requires a corresponding upload to ca-certificates.

Didn't notice that the re-assign didn't work. ca-certificates also has a pull
request on gitlab.

Hi all,

The upload of ca-certificates-java happened. Julien had objections to
some of the changes in the MR [1], quoting:
"""
I'd rather not change the versioning scheme.

I have no plans to upgrade the bundle in stable, but if that is a worry
then there can be a virtual package to track changes that affect the
-java package.
"""

Can somebody with a better understanding of the situation comment on
what *needs* to be done to fix this bug (and are not nice to haves)? (A
breaks? more?) @Julien, are all commits in the MR acceptable *except*
the versioning one?

Paul

[1] https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6

Hi,

It's been 2.5 years since the last update on this bug, which was Paul
Gevers asking whether it would be acceptable to apply Andreas' patch
without the versioning scheme change, but this went unanswered.

This bug is now in the list of RC bugs for trixie, having it already
been tagged bookworm-can-defer and bullseye-can-defer, I fear it's
heading towards getting a third of those.

Julian, does the approach proposed by Andreas in
https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6 make
sense, apart from the versioning scheme change?

Otherwise, I'm wondering whether a 6 year old RC bug that has remained
silent for years with no consequences actually warrants staying at RC
(and even open). Is this bug still causing problems, after that
ca-certificates-java changed the dependencies?