Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Michael Shuler]

I've been able to test this error by creating a bogus symlink in
/etc/ssl/certs and I committed a patch that removes any orphan symlinks,
prior to running `openssl rehash`.

https://salsa.debian.org/debian/ca-certificates/commit/cfe7064cb707ed2e8ac587877c1153029d46dc28

-- 
Kind regards,
Michael.

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi Michael,

Michael Shuler wrote:
> [x] I intend to find the time between work, family, and multiple other
> projects to attempt to reliably reproduce the problem, in order to
> intelligently answer the above.

Much appreciated, thanks!

In the hope that it helps you to track down this issue, here are the
debconf settings of my second affected machine, the i386 one. (The
other machine's debconf settings are in the original report.)

# debconf-get-selections | fgrep ca-cert
ca-certificates ca-certificates/enable_crts multiselect 
CAcert/class3.crt, CAcert/root.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/DigiCert_Assured_ID_Root_CA.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/GeoTrust_Global_CA_2.crt, mozilla/GeoTrust_Global_CA.crt, 
mozilla/GeoTrust_Primary_Certification_Authority.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, 
mozilla/GeoTrust_Universal_CA_2.crt, mozilla/GeoTrust_Universal_CA.crt, 
mozilla/IdenTrust_Commercial_Root_CA_1.crt, 
mozilla/IdenTrust_Public_Sector_Root_CA_1.crt, mozilla/ISRG_Root_X1.crt, 
mozilla/QuoVadis_Root_CA_1_G3.crt, mozilla/QuoVadis_Root_CA_2.crt, 
mozilla/QuoVadis_Root_CA_2_G3.crt, mozilla/QuoVadis_Root_CA_3.crt, 
mozilla/QuoVadis_Root_CA_3_G3.crt, mozilla/QuoVadis_Root_CA.crt, 
mozilla/Swisscom_Root_CA_1.crt, mozilla/Swisscom_Root_CA_2.crt, 
mozilla/Swisscom_Root_EV_CA_2.crt, mozilla/SwissSign_Gold_CA_-_G2.crt, 
mozilla/SwissSign_Silver_CA_-_G2.crt, mozilla/thawte_Primary_Root_CA.crt, 
mozilla/thawte_Primary_Root_CA_-_G2.crt, 
mozilla/thawte_Primary_Root_CA_-_G3.crt, 
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt, 
mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.crt, 
mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt, 
mozilla/VeriSign_Universal_Root_Certification_Authority.crt,
ca-certificates ca-certificates/new_crtsmultiselect
ca-certificates ca-certificates/trust_new_crts  select  ask

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Michael Shuler]

On 06/20/2018 04:33 PM, Sebastian Andrzej Siewior wrote:

On 2018-06-13 08:19:32 [+0200], To Axel Beckert wrote:

I asked upstream what they thing about ignoring these errors because the
perl script does so. On the other hand what about cleaning up these
dangling symlinks?


ca-certificate maintainers: what do we do here?

[ ] we intend to figure out why there are dangling symlinks, no need to
 change "openssl rehash" in anyway.

[ ] we intend to figure out why there are dangling symlinks but in the
 meantime "openssl rehash" should not error out on them.

[ ] "openssl rehash" should not error out on certificates which can not
 be opened. This is the old behavioud and required due to $reason.


[x] I intend to find the time between work, family, and multiple other
projects to attempt to reliably reproduce the problem, in order to
intelligently answer the above.

--
Kind regards,
Michael

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-06-13 08:19:32 [+0200], To Axel Beckert wrote:
> I asked upstream what they thing about ignoring these errors because the
> perl script does so. On the other hand what about cleaning up these
> dangling symlinks?

ca-certificate maintainers: what do we do here?

[ ] we intend to figure out why there are dangling symlinks, no need to
change "openssl rehash" in anyway.

[ ] we intend to figure out why there are dangling symlinks but in the
meantime "openssl rehash" should not error out on them.

[ ] "openssl rehash" should not error out on certificates which can not
be opened. This is the old behavioud and required due to $reason.
 
> > Regards, Axel

Sebastian

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-06-13 00:10:57 [+0200], Axel Beckert wrote:
> Hi Sebastian,
Hi Axel,

> Sebastian Andrzej Siewior wrote:
> > > I don't think so unless a future upload of OpenSSL to unstable fixes
> > > this. The recent one to unstable didn't.
> > 
> > forwarded https://github.com/openssl/openssl/issues/6475
> > 
> > Just a little question: The missing certificates:
> > |rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file
> > |rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file
> > |rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file
> > |rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file
> > 
> > where are they from?
> 
> From the ca-certificates package I assume. At least those errors go
> away if I downgrade to 20170717 again and they reappear as soon as I
> upgrade to 20180409 on that machine. At least the file names are the
> same as in my mail from 12th of April[1] (just in different order).
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895482#10
> 
> I just checked: All four CAs are CAs I've chosen to be enabled. But
> they're by far not the only CAs which are enabled from ca-certificates
> on that machine. So I have no idea what makes those four special.

Okay. So this is "normal" debconf and nothing more. Just wanted to make
sure.

> > Is there something specific you did to get those
> > symlinks which now don't belong to a real file?
> 
> No. As mentioned in the initial report, I have ca-certificates to ask
> me every time on new CAs if I want to enable them or not. And I'm
> rather conservative with enabling CAs. I also do this on most of my
> machines, usually with slight differences in the list of enabled CAs.
> Nevertheless this only happened on two of my machines.

I asked upstream what they thing about ignoring these errors because the
perl script does so. On the other hand what about cleaning up these
dangling symlinks?

>   Regards, Axel

Sebastian

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi Sebastian,

Sebastian Andrzej Siewior wrote:
> > I don't think so unless a future upload of OpenSSL to unstable fixes
> > this. The recent one to unstable didn't.
> 
> forwarded https://github.com/openssl/openssl/issues/6475
> 
> Just a little question: The missing certificates:
> |rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file
> |rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file
> |rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file
> |rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file
> 
> where are they from?

From the ca-certificates package I assume. At least those errors go
away if I downgrade to 20170717 again and they reappear as soon as I
upgrade to 20180409 on that machine. At least the file names are the
same as in my mail from 12th of April[1] (just in different order).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895482#10

I just checked: All four CAs are CAs I've chosen to be enabled. But
they're by far not the only CAs which are enabled from ca-certificates
on that machine. So I have no idea what makes those four special.

From debconf-get-selections:

ca-certificates ca-certificates/enable_crts multiselect 
CAcert/class3.crt, CAcert/root.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/DigiCert_Assured_ID_Root_CA.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/GeoTrust_Global_CA_2.crt, mozilla/GeoTrust_Global_CA.crt, 
mozilla/GeoTrust_Primary_Certification_Authority.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, 
mozilla/GeoTrust_Universal_CA_2.crt, mozilla/GeoTrust_Universal_CA.crt, 
mozilla/IdenTrust_Commercial_Root_CA_1.crt, 
mozilla/IdenTrust_Public_Sector_Root_CA_1.crt, mozilla/ISRG_Root_X1.crt, 
mozilla/QuoVadis_Root_CA_1_G3.crt, mozilla/QuoVadis_Root_CA_2.crt, 
mozilla/QuoVadis_Root_CA_2_G3.crt, mozilla/QuoVadis_Root_CA_3.crt, 
mozilla/QuoVadis_Root_CA_3_G3.crt, mozilla/QuoVadis_Root_CA.crt, 
mozilla/Swisscom_Root_CA_1.crt, mozilla/Swisscom_Root_CA_2.crt, 
mozilla/Swisscom_Root_EV_CA_2.crt, mozilla/SwissSign_Gold_CA_-_G2.crt, 
mozilla/SwissSign_Silver_CA_-_G2.crt, mozilla/thawte_Primary_Root_CA.crt, 
mozilla/thawte_Primary_Root_CA_-_G2.crt, 
mozilla/thawte_Primary_Root_CA_-_G3.crt, 
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt, 
mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.crt, 
mozilla/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt, 
mozilla/VeriSign_Universal_Root_Certification_Authority.crt,

> Is there something specific you did to get those
> symlinks which now don't belong to a real file?

No. As mentioned in the initial report, I have ca-certificates to ask
me every time on new CAs if I want to enable them or not. And I'm
rather conservative with enabling CAs. I also do this on most of my
machines, usually with slight differences in the list of enabled CAs.
Nevertheless this only happened on two of my machines.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-06-12 22:29:42 [+0200], Axel Beckert wrote:
> Shall I try the version from Experimental, too?
no.

> > (Should some Breaks be added, Depends made stricter?)
> 
> I don't think so unless a future upload of OpenSSL to unstable fixes
> this. The recent one to unstable didn't.

forwarded https://github.com/openssl/openssl/issues/6475

Just a little question: The missing certificates:
|rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file
|rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file
|rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file
|rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file

where are they from? Is there something specific you did to get those
symlinks which now don't belong to a real file?

>   Regards, Axel

Sebastian

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi Kurt,

Kurt Roeckx wrote:
> > > Given that this openssl update is now in testing, should we close or at
> > > least downgrade this bug so ca-certificates can migrate?
> > 
> > I just unhold ca-certificates 20170717 and upgraded it to 20180409 on
> > one of my affected machines (the i386 one) and unfortunately, the
> > issue (at least mine, which is #895482 with exit status 4, so only
> > Cc'ing that bug report) doesn't seem to fixed:
> 
> Which openssl version do you have installed?

Valid question. I should have mentioned that explicitly.

It's the current version from unstable/testing:

104/0/0 root@loadrunner:pts/3 22:16:35 [~] # apt-cache policy openssl
openssl:
  Installed: 1.1.0h-4
  Candidate: 1.1.0h-4
  Version table:
 1.1.1~~pre7-1 110
110 https://debian.ethz.ch/debian experimental/main i386 Packages
 *** 1.1.0h-4 990
990 https://debian.ethz.ch/debian sid/main i386 Packages
500 https://debian.ethz.ch/debian testing/main i386 Packages
100 /var/lib/dpkg/status
105/0/0 root@loadrunner:pts/3 22:26:00 [~] # 

Shall I try the version from Experimental, too?

> (Should some Breaks be added, Depends made stricter?)

I don't think so unless a future upload of OpenSSL to unstable fixes
this. The recent one to unstable didn't.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Kurt Roeckx]

On Tue, Jun 12, 2018 at 09:57:56PM +0200, Axel Beckert wrote:
> Hi,
> 
> Thijs Kinkhorst wrote:
> > >> I've read about this bug (and the other one) on d-devel. I uploaded
> > >> recently a new version of openssl to unstable (1.1.0h-3)which changes
> > >> the exit code of "openssl rehash" to zero in case of a duplicate or if a
> > >> certificate can no be open.
> > >> I left this bug open in case the maintainer of this package wants to
> > >> investigate why there are duplicates or non-existing certificates.
> > >
> > > Thanks for the update, Sebastian.
> > >
> > > OpenSSL commit for my own reference and for others, if interested:
> > > https://github.com/openssl/openssl/commit/e6a833cb97ed762408b57ea3efa83bd10c1d2a78
> > 
> > Given that this openssl update is now in testing, should we close or at
> > least downgrade this bug so ca-certificates can migrate?
> 
> I just unhold ca-certificates 20170717 and upgraded it to 20180409 on
> one of my affected machines (the i386 one) and unfortunately, the
> issue (at least mine, which is #895482 with exit status 4, so only
> Cc'ing that bug report) doesn't seem to fixed:

Which openssl version do you have installed?

(Should some Breaks be added, Depends made stricter?)


Kurt

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi,

Thijs Kinkhorst wrote:
> >> I've read about this bug (and the other one) on d-devel. I uploaded
> >> recently a new version of openssl to unstable (1.1.0h-3)which changes
> >> the exit code of "openssl rehash" to zero in case of a duplicate or if a
> >> certificate can no be open.
> >> I left this bug open in case the maintainer of this package wants to
> >> investigate why there are duplicates or non-existing certificates.
> >
> > Thanks for the update, Sebastian.
> >
> > OpenSSL commit for my own reference and for others, if interested:
> > https://github.com/openssl/openssl/commit/e6a833cb97ed762408b57ea3efa83bd10c1d2a78
> 
> Given that this openssl update is now in testing, should we close or at
> least downgrade this bug so ca-certificates can migrate?

I just unhold ca-certificates 20170717 and upgraded it to 20180409 on
one of my affected machines (the i386 one) and unfortunately, the
issue (at least mine, which is #895482 with exit status 4, so only
Cc'ing that bug report) doesn't seem to fixed:

Performing actions...
Preconfiguring packages ...
(Reading database ... 936122 files and directories currently installed.)
Preparing to unpack .../ca-certificates_20180409_all.deb ...
Unpacking ca-certificates (20180409) over (20170717) ...
[…]
Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/GeoTrust_Global_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_1.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_EV_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file
rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file
rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file
rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
Processing triggers for hicolor-icon-theme (0.17-2) ...
Setting up libcups2:i386 (2.2.8-3) ...
Setting up libcupsimage2:i386 (2.2.8-3) ...
Processing triggers for libc-bin (2.27-3) ...
Errors were encountered while processing:
 ca-certificates
[master c040eace] committing changes in /etc after apt run
 45 files changed, 1039 deletions(-)
 delete mode 12 ssl/certs/00673b5b.0
 delete mode 12 ssl/certs/034868d6.0
 delete mode 12 ssl/certs/12d55845.0
 delete mode 12 ssl/certs/1f58a078.0
 delete mode 12 ssl/certs/27af790d.0
 delete mode 12 ssl/certs/399e7759.0
 delete mode 12 ssl/certs/3c860d51.0
 delete mode 12 ssl/certs/3efd4dc0.0
 delete mode 12 ssl/certs/450c6e38.0
 delete mode 12 ssl/certs/4be590e0.0
 delete mode 12 ssl/certs/5046c355.0
 delete mode 12 ssl/certs/524d9b43.0
 delete mode 12 ssl/certs/52b525c7.0
 delete mode 12 ssl/certs/57692373.0
 delete mode 12 ssl/certs/5cf9d536.0
 delete mode 12 ssl/certs/5d66db40.0
 delete mode 12 ssl/certs/5e4e69e7.0
 delete mode 12 ssl/certs/5ed36f99.0
 delete mode 12 ssl/certs/6187b673.0
 delete mode 12 ssl/certs/667c66d4.0
 delete mode 12 ssl/certs/67495436.0
 delete mode 12 ssl/certs/69105f4f.0
 delete mode 12 ssl/certs/7999be0d.0
 delete mode 12 ssl/certs/7a819ef2.0
 delete mode 12 ssl/certs/7d453d8f.0
 delete mode 12 ssl/certs/8028ce6e.0
 delete mode 12 ssl/certs/81b9768f.0
 delete mode 12 ssl/certs/87753b0d.0
 delete mode 12 ssl/certs/9339512a.0
 delete mode 12 ssl/certs/9772ca32.0
 delete mode 12 ssl/certs/9ab62355.0
 delete mode 12 ssl/certs/9f129ada.0
 delete mode 12 ssl/certs/a7d2cf64.0
 delete mode 12 ssl/certs/c7e2a638.0
 delete mode 100644 ssl/certs/ca-certificates.crt
 delete mode 12 ssl/certs/cbeee9e2.0
 delete mode 12 ssl/certs/d18e9066.0
 delete mode 12 ssl/certs/d4c339cb.0
 delete mode 12 ssl/certs/e442e424.0
 delete mode 12 ssl/certs/e5662767.0
 delete mode 12 ssl/certs/e60bf0c0.0
 delete mode 12 ssl/certs/e775ed2d.0
 delete mode 12 ssl/certs/e9f92b43.0
 delete mode 12 ssl/certs/facacbc6.0
[…]
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/GeoTrust_Global_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_1.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: 

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Thijs Kinkhorst]

On Wed, May 30, 2018 20:22, Michael Shuler wrote:
> On 05/30/2018 12:46 PM, Sebastian Andrzej Siewior wrote:
>>
>> I've read about this bug (and the other one) on d-devel. I uploaded
>> recently a new version of openssl to unstable (1.1.0h-3)which changes
>> the exit code of "openssl rehash" to zero in case of a duplicate or if a
>> certificate can no be open.
>> I left this bug open in case the maintainer of this package wants to
>> investigate why there are duplicates or non-existing certificates.
>
> Thanks for the update, Sebastian.
>
> OpenSSL commit for my own reference and for others, if interested:
> https://github.com/openssl/openssl/commit/e6a833cb97ed762408b57ea3efa83bd10c1d2a78

Given that this openssl update is now in testing, should we close or at
least downgrade this bug so ca-certificates can migrate?


Cheers,
Thijs

Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Michael Shuler]

On 05/30/2018 12:46 PM, Sebastian Andrzej Siewior wrote:


I've read about this bug (and the other one) on d-devel. I uploaded
recently a new version of openssl to unstable (1.1.0h-3)which changes
the exit code of "openssl rehash" to zero in case of a duplicate or if a
certificate can no be open.
I left this bug open in case the maintainer of this package wants to
investigate why there are duplicates or non-existing certificates.


Thanks for the update, Sebastian.

OpenSSL commit for my own reference and for others, if interested:
https://github.com/openssl/openssl/commit/e6a833cb97ed762408b57ea3efa83bd10c1d2a78

--
Kind regards,
Michael

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-04-22 16:55:21 [+0200], Axel Beckert wrote:
> Hi Michael,
Hi,

> Michael Shuler wrote:
> > Thanks for the details. #895473 reported a similar error on locally
> > installed CA certificates, which I think may be related.
> 
> That other bug report indeed looks similar albeit not identical.
…
> (That's why I've now downgraded ca-certificates on my two affected
> machines.)

I've read about this bug (and the other one) on d-devel. I uploaded
recently a new version of openssl to unstable (1.1.0h-3)which changes
the exit code of "openssl rehash" to zero in case of a duplicate or if a
certificate can no be open.
I left this bug open in case the maintainer of this package wants to
investigate why there are duplicates or non-existing certificates.

>   Regards, Axel

Sebastian

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi Michael,

Michael Shuler wrote:
> Thanks for the details. #895473 reported a similar error on locally
> installed CA certificates, which I think may be related.

That other bug report indeed looks similar albeit not identical.

> I've tried a number of upgrades from a March 29 unstable chroot, as well
> as from stretch to unstable on openstack instances, on both amd64 and
> i386 (I don't think arch is dependent), and I've been unable to get a
> similar error to present itself.

Doesn't surprise me. From about ten machines with Debian unstable, I
only ran into that issue on two machines, one amd64 and one i386.

> Each way I've tried, I get the package-removed certificates prefixed
> properly and no errors, so haven't been able to reproduce this, yet. I
> will keep trying with different options and see if I can figure out
> where the problem is. If someone has a good way to reproduce, I'd
> appreciate it!

Sorry, can't help there at the moment as I have no idea what makes the
two machines, on which I ran into it, so special. I just wanted to add
some more facts:

Downgrading ca-certificates to the version from testing (20170717)
fixes the issue and seems to clean up the broken files, symlinks, …
well.

On all machines I ran into that issue I was no more able to run "apt
update" or similar, since I use HTTPS in my sources.list and
certificate validation failed and hence I was unable to download new
package lists and hence unable to download any package updates, too.

(That's why I've now downgraded ca-certificates on my two affected
machines.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Michael Shuler]

Thanks for the details. #895473 reported a similar error on locally
installed CA certificates, which I think may be related.

Each of the list of `rehash: skipping .. cannot open file` in your
errors appears to be on CAs that were removed in the package during this
update, so somewhere we have a problem with `openssl rehash` trying to
link to files we removed, but for some reason were not prefixed with '!'
in /etc/ca-certificates.conf.

I've tried a number of upgrades from a March 29 unstable chroot, as well
as from stretch to unstable on openstack instances, on both amd64 and
i386 (I don't think arch is dependent), and I've been unable to get a
similar error to present itself.

Each way I've tried, I get the package-removed certificates prefixed
properly and no errors, so haven't been able to reproduce this, yet. I
will keep trying with different options and see if I can figure out
where the problem is. If someone has a good way to reproduce, I'd
appreciate it!

-- 
Kind regards,
Michael

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Hi,

Axel Beckert wrote:
> On other sid installations (including architectures amd64, i386 and
> armhf), the upgrade worked fine, […]

Correction: It failed on one i386 sid machine, too:

Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/GeoTrust_Global_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_1.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Swisscom_Root_EV_CA_2.crt not found, but 
listed in /etc/ca-certificates.conf.
rehash: skipping Swisscom_Root_CA_1.pem, cannot open file
rehash: skipping Swisscom_Root_CA_2.pem, cannot open file
rehash: skipping GeoTrust_Global_CA_2.pem, cannot open file
rehash: skipping Swisscom_Root_EV_CA_2.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
Errors were encountered while processing:
 ca-certificates

Still, it worked fine on at least one amd64 and one armhf machine.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Axel Beckert]

Package: ca-certificates
Version: 20180409
Severity: serious

Upgrading ca-certificates from 20170717 to 20180409 fails for me as
follows on one machine:

Before unpacking, I have been shown this dialog, which I acknowledged
by pressing enter:

  ┌┤ ca-certificates configuration 
├─┐
  │ During upgrades, new certificates will be added. Please choose 
those you trust.  │
  │ 
 │
  │ New certificates to activate:   
 │
  │ 
 │
  │[ ] mozilla/GDCA_TrustAUTH_R5_ROOT.crt   
 │
  │[ ] mozilla/SSL.com_EV_Root_Certification_Authority_ECC.crt  
 │
  │[ ] mozilla/SSL.com_EV_Root_Certification_Authority_RSA_R2.crt   
 │
  │[ ] mozilla/SSL.com_Root_Certification_Authority_ECC.crt 
 │
  │[ ] mozilla/SSL.com_Root_Certification_Authority_RSA.crt 
 │
  │[ ] mozilla/TrustCor_ECA-1.crt   
 │
  │[ ] mozilla/TrustCor_RootCert_CA-1.crt   
 │
  │[ ] mozilla/TrustCor_RootCert_CA-2.crt   
 │
  │ 
 │
  │ 
 │
  │ 
 │
  │ 
 │
  
└──┘

Unpacking went fine:

Preparing to unpack .../04-ca-certificates_20180409_all.deb ...
Unpacking ca-certificates (20180409) over (20170717) ...

The first as well as the second try to configure ca-certificates
failed identically:

Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/AddTrust_Public_Services_Root.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/AddTrust_Qualified_Certificates_Root.crt 
not found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/UTN_USERFirst_Hardware_Root_CA.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt not found, but listed 
in /etc/ca-certificates.conf.
rehash: skipping DST_ACES_CA_X6.pem, cannot open file
rehash: skipping AddTrust_Qualified_Certificates_Root.pem, cannot open file
rehash: skipping UTN_USERFirst_Hardware_Root_CA.pem, cannot open file
rehash: skipping AddTrust_Public_Services_Root.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
[…]
Errors were encountered while processing:
 ca-certificates
[…]
E: Sub-process /usr/bin/dpkg returned an error code (1)
[…]
Setting up ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
W: /usr/share/ca-certificates/mozilla/AddTrust_Public_Services_Root.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/AddTrust_Qualified_Certificates_Root.crt 
not found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/UTN_USERFirst_Hardware_Root_CA.crt not 
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/DST_ACES_CA_X6.crt not found, but listed 
in /etc/ca-certificates.conf.
rehash: skipping DST_ACES_CA_X6.pem, cannot open file
rehash: skipping AddTrust_Qualified_Certificates_Root.pem, cannot open file
rehash: skipping UTN_USERFirst_Hardware_Root_CA.pem, cannot open file
rehash: skipping AddTrust_Public_Services_Root.pem, cannot open file
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 4
Errors were encountered while processing:
 ca-certificates

On other sid installations (including architectures amd64, i386 and
armhf), the upgrade worked fine, despite most (if not all) of my
systems have similar ca-certificates settings, namely
"ca-certificates/trust_new_crts: ask" and just a few CAs
selected. It's though very likely that the actual list of CAs differs
from installation to installation as I enabled further ones per
machine as needed.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110,