Package: ca-certificates-java Version: 20160321 Severity: serious User: debian...@lists.debian.org Usertags: piuparts
Hi, the setup_path routine in ca-certificates-java.postinst does not take into account that it might not find a known jre. In that case $jvm and $JAVA_HOME will be invalid. This usually happens if a new package starts providing java7-runtime-headless. I simulated this in a minimal chroot by creating a java7-runtime-headless package with equivs and installing it (but installing no other jre). Thereafter installing ca-certificates-java results in: # apt-get install ca-certificates-java Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libnspr4 libnss3 The following NEW packages will be installed: ca-certificates-java libnspr4 libnss3 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/1286 kB of archives. After this operation, 4204 kB of additional disk space will be used. Do you want to continue? [Y/n] debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76, <> line 3.) debconf: falling back to frontend: Readline Selecting previously unselected package libnspr4:amd64. (Reading database ... 16913 files and directories currently installed.) Preparing to unpack .../libnspr4_2%3a4.12-2_amd64.deb ... Unpacking libnspr4:amd64 (2:4.12-2) ... Selecting previously unselected package libnss3:amd64. Preparing to unpack .../libnss3_2%3a3.23-2_amd64.deb ... Unpacking libnss3:amd64 (2:3.23-2) ... Selecting previously unselected package ca-certificates-java. Preparing to unpack .../ca-certificates-java_20160321_all.deb ... Unpacking ca-certificates-java (20160321) ... Processing triggers for libc-bin (2.22-6) ... Processing triggers for ca-certificates (20160104) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Setting up libnspr4:amd64 (2:4.12-2) ... Setting up libnss3:amd64 (2:3.23-2) ... Setting up ca-certificates-java (20160321) ... /var/lib/dpkg/info/ca-certificates-java.postinst: line 57: java: command not found /var/lib/dpkg/info/ca-certificates-java.postinst: line 70: java: command not found done. Processing triggers for libc-bin (2.22-6) ... Processing triggers for ca-certificates (20160104) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... /etc/ca-certificates/update.d/jks-keystore: 86: /etc/ca-certificates/update.d/jks-keystore: java: not found E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. done. # echo $? 0 Postinst and trigger spew a lot of errors, no java keystore has been created/updated, but apt-get finished successfully. I assume that ca-certificates-java is *not correctly installed* in this situation and will cause failures in packages that Depend on it and actually do use it. Thus the Severity: serious. I noticed this problem in a piuparts log where ca-certificates-java (20140324) was installed along openjdk-8-jre-headless:amd64 (8u72-b15-2), producing the same 'java: command not found' errors. The piuparts test finished successfully, that logfile is attached. equivs was just an easy way to reproduce it with current ca-certificates-java. Current ca-certificates-java knows about openjdk-{7,8,9} and the oracle equivalents, but there will probably be a -10 in the future (or some vendor might provide yet another implementation of java7-runtime-headless in yet another path ... /usr/lib/jvm/vendor-java-42-yet-another-jre). Andreas
libeasymock-java_3.3.1+ds-3.log.gz
Description: application/gzip
__ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.