https://bugs.kde.org/show_bug.cgi?id=385687
Andre Heinecke <aheine...@intevation.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |https://dev.gnupg.org/T3948
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
CC| |aheine...@intevation.de
--- Comment #1 from Andre Heinecke <aheine...@intevation.de> ---
Hello,
(In reply to ekaratsiolis from comment #0)
> for a project we evaluate the certification path construction and validation
> of different libraries and applications. One application on this set is
> KMail 5.1.3 with Kleopatra 2.2.0. We found a few issues which I present to
> you. Please find them at the end of the email.
Which GnuPG Version did you use for testing?
You can directly use GnuPG to test mails e.g.:
~/arbeit/kf5/build/gnupg/tools/gpgparsemail --crypto
smime/CERT_PATH_ALGO_STRENGTH_01.eml
Most of the issues here need to be fixed upstream as KMail itself does not do
any crypto, certificate checking or CRL fetching / caching. This is all done by
the GnuPG System. KMail is just a fronted.
These issues should have been raised in the GnuPG tracker (
https://dev.gnupg.org ) or on one of the GnuPG Mailing lists. So apologies for
the late reply but it was overlooked here a bit as the KMail developers are not
really responsible.
I've opened an upstream report https://dev.gnupg.org/T3948
> Especially CERT_PATH_COMMON_05 is interesting. In this case a certificate
> with wrong encoding is placed in the S/MIME structure. In this case the
> signature is ignored totally and the email appears as a standard email
> without signature.
This indeed appears to be a kmail issue. Although I would argue that showing an
invalid signed mail as secure as an unsigned mail is not very harmful.
> Also the CRL tests could not be performed. Every CRL for each test is placed
> in a distinct crldp on the same server. Once the first test where one CRL is
> downloaded runs, it seems that for all later tests only the first CRL is
> used (cahcing), the new CRLs are not downloaded and the application
> evaluates the first CRL for resolving the revocation status of a
> certificate. Therefore almost every CRL test fails.
I can't really reproduce this there are crlDp's like:
http://certpath_test_host:8095/cert_path_crl_02/cert_path_crl_02_sub_ca_crl.crl
ldap://certpath_test_host:389
CN=cert_path_crl_02_sub_ca_crl,OU=cert_path_crl_02,dc=certpath_test_host?certificateRevocationList?base?objectClass=cRLDistributionPoint
which of course won't work for me. Again. This should be reproducible by just
using GPGSM without KMail.
> Test Name | Evaluation | Expected Result | Application result |
I'll try to give it a more detailed look on Monday in the GnuPG tracker,
afterwards I can probably better say if there is something that KMail does
wrong, although I don't expect it (except for the minor problem where an
invalid signature is not shown)
Best Regards,
Andre Heinecke
--
You are receiving this mail because:
You are watching all bug changes.
