Summary: | Kleopatra crashes with segmentation fault on startup after importing PEM file | ||
---|---|---|---|
Product: | [Applications] kleopatra | Reporter: | Guido Winkelmann <guido-kdebugs> |
Component: | general | Assignee: | Andre Heinecke <aheinecke> |
Status: | CONFIRMED --- | ||
Severity: | crash | CC: | arnold338250622, kdenis, kdepim-bugs, mutz |
Priority: | NOR | ||
Version: | 2.3.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | The pem file that caused the crash after it was imported |
Description
Guido Winkelmann
2017-02-16 22:53:20 UTC
Thank you for your detailed report. I've had a brief look at the code and don't see an obvious recursion possiblity. As you write that this happens after importing a specific certificate could you attach that certificate here or send it to aheinecke@intevation.de Additionally it would be great if you could check with "gpgsm -k" if the output looks fishy already. (e.g. one certificate is repeated a lot) gpgsm -k looks like it's working fine here and doesn't show anything that looks fishy to me. I just had another look into the PEM file I imported, and I noticed something that could potentially, without having actually looked at the code, explain the out of control recursion: The Comodo CA certificate is signed by AddTrust External CA Root, which itself is cross signed by UTN - DATACorp SGC, meaning UTN - DATACorp SGC is itself again signed by AddTrust. This cross-signing thing is a fairly obscure feature of X.509 certificates that, until recently, was very rarely seen in the wild. If a programmer is not aware of this possibility, and didn't think to check X.509 trust paths for loops or at least limit the length of support trust chains, then trying to build a trust path for a certificate with such a cross-signed CA in there somewhere will usually lead to endless recursion. Created attachment 104098 [details]
The pem file that caused the crash after it was imported
Thank you very much. I can reproduce the problem with this certificate and I agree about the likely cause. But there is also an underlying problem in GpgSM. It does not handle the certificate well either. When importing it I got warnings about "Certificate chain too long" and while gpgsm -k looks ok if you do a "gpgsm -k --with-validation" causing it to check the certificate chain it takes a while and then shows: [checking the CRL failed: Bad certificate chain] [certificate is bad: Bad certificate chain] You might want to consider if this was caused by a Qt bug that was resolved fixed in 5.8, as described in Bug 361895, Comment 1. No it's a bug in GpgSM / Kleopatra. This special certificate is not handled by GpgSM correctly and Kleopatra can't cope with it. I'm not sure if this is only an upstream bug without further analysis. At least Kleopatra should handle this. I'll try to look at it soon. User certificates from KIT seem to suffer from this bug as well. They are cross signed by an old chain with root-CA "Deutsche Telekom Root CA 2" and a new one with root-CA "T-TeleSec GlobalRoot Class 2". User certificates are available here (this is mine) https://search.ca.kit.edu/pubdownload/pem/10311245368690295726648917385 Installing the new root-CA by hand from https://pki.pca.dfn.de/kit-ca/cgi-bin/pub/pki?cmd=getStaticPage;name=index;id=2&RA_ID=0 seems to enforce the new chain and solve the invalid old root. Nevertheless the valid path should be found without manual intervention. As of 2022-03-23, the bug is still present in the released version 21.08.3, but does appear to be fixed in the newest git version. (In reply to Guido Winkelmann from comment #9) > As of 2022-03-23, the bug is still present in the released version 21.08.3, > but does appear to be fixed in the newest git version. Does anybody happen to know which commit fixed it, and whether it was in kleopatra itself or in libkleo? |