Since this commit between 7.6 and 24.2.0.0.alpha1 I can't X.509 sign ODF files anymore. (ODF signing! PDF signing is NOT affected) https://git.libreoffice.org/core/+/bfd479abf0d1d8ce36c3b0dcc6c824216f88a95b%5E!/ Commit message: > Update libxmlsec to 1.3.1 > This time try to do it in a way that doesn't re-introduce tdf#155034, > i.e. patch out code that would use NSS symbols which are in the RHEL7 > baseline, but are not in Ubuntu 18.04. This is all code like RSA OAEP or > AES GCM which is relatively new, so not really required for our > signature needs. > It also helps that this release has a lowered baseline for NSS. Tested OS: Debian-12 In LO-7.6 X.509 ODF signing worked with currently valid X.509 certificates. Now in LO-24.2 I get this on STDERR: warn:xmlsecurity.xmlsec:3979175:3979175:xmlsecurity/source/xmlsec/errorcallback.cxx:54: x509vfy.c:480: xmlSecNssX509StoreVerifyCert() '' '' 71 'subject="E=EMAIL@EXAMPLE.ORG,CN=FIRSTNAME LASTNAME"; reason=-8179' Interestingly in LO-7.6 X.509 ODF signing with outdated X.509 certificates also worked. But with LO-24.2 I get this on STDERR: warn:xmlsecurity.xmlsec:3976088:3976088:xmlsecurity/source/xmlsec/errorcallback.cxx:54: x509vfy.c:470: xmlSecNssX509StoreVerifyCert() '' '' 76 'subject="E=EMAIL@EXAMPLE.ORG,CN=FIRSTNAME LASTNAME"; reason=expired' -- Bug moved out of this meta bug: (OpenPGP) - [META] OpenPGP bugs and enhancements Bug 158839 comment 1, section: X.509: ODF signing: X.509 signing doesn't work Turns out this has probably nothing to do with GPG. So there's no further relation between bug 158839 and this bug.
> Interestingly in LO-7.6 X.509 ODF signing with outdated X.509 certificates also worked. Hmm, this sounds like a good change, we should not allow signing with invalid certs, including expired ones, I would say. What do you think? Related: did you see the xmlsecurity/qa/create-certs/create-certs.sh script that gives you a non-expired signing cert for testing purposes?
> We should not allow signing with invalid certs, including expired ones, I would say. What do you think? 💯
(In reply to Miklos Vajna from comment #1) > > Interestingly in LO-7.6 X.509 ODF signing with outdated X.509 certificates also worked. > > Hmm, this sounds like a good change, we should not allow signing with > invalid certs, including expired ones, I would say. What do you think? -> This bug is about the regression, that no more ODF signing is possible since LibreOffice-24.2 (libxmlsec-1.3.1). The thing about the outdated cert was just a side note. -> If you like to discuss this in depth please move it to a new ticket. I would maybe warn the user that he's using an invalid cert, but not block the action. There's always a way to forcefully create a signature with an invalid cert (e.g. change system time for outdated certs). Checking the validity is the job of the software validating the signature, not the job of the software creating the signature! > Related: did you see the xmlsecurity/qa/create-certs/create-certs.sh script > that gives you a non-expired signing cert for testing purposes? I've just tested that. Those certs also don't work with current LO master. Before I've used a www.cacert.org cert for testing.
> I've just tested that. Those certs also don't work with current LO master. I see. We need to track down what is the different in your master build vs my master build where it does work to run ./create-certs.sh, import the result to the Firefox profile, point LO to use it, then then I can just sign a new document with the just created X509 certificate. My build uses --enable-dbgutil and --without-system-nss, so both xmlsec and nss are internal. Thanks.
(In reply to Miklos Vajna from comment #4) > [...] > My build uses --enable-dbgutil and --without-system-nss, so both xmlsec and > nss are internal. Thanks. I've bisected the problem using the builds from this binary repo. https://bibisect.libreoffice.org/linux-64-24.2 First bad commit in that repo is: cfe7f35909ab57642b1ca64de1fbc033ce6c2a60 I've also reproduced the problem with my local master builds in the last weeks. And I'm also using --enable-dbgutil for those builds, but I have not used --without-system-nss and config.log says "checking which nss to use" -> "result: external". So I just build with --enable-dbgutil and --without-system-nss. But X.509 ODF signing is still broken. Then I installed the libxmlsec1-dev Debian-12 package which wasn't installed before (Debian-12 comes with libxmlsec1-1.2.37). And I rebuild using --with-system-nss and --with-system-xmlsec. And with that build X.509 ODF signing works. But I guess it's simply because Debian-12 ships libxmlsec version 1.2.37 instead of 1.3.1. Interestingly signing and encrypting ODF with GPG seems to work always. My system: OS: Debian-12 (x86_64) Mozilla profile is freshly created with Thunderbird 115.12.0 (64-Bit build Debian-12).
Aha, exciting. :-) So probably this will be a problem in upstream xmlsec, but most likely Aleksey don't want to build libreoffice to debug this, so we should make this as easy for him as possible. It may make sense to file an issue at https://github.com/lsh123/xmlsec/ and point to this bug. If signing fails, we should emit warnings in the dbgutil case on stderr. Could you please check: 1) In XMLSignature_NssImpl::generate(), when we do the xmlSecDSigCtxSign() call that is the actual signing, do you get an error? 2) If you get an error, then ideally we get error details via the xmlsec log callback, can you check if errorCallback() gets called? If so, do we get any details there, why the signing fails? 3) Last idea: we have this own code at verifyCertificate(), there we emit lots of SAL_INFOs, can you check that finds no errors? Thanks. FWIW I'm on openSUSE Leap 15.5, I guess there is some openSUSE vs Debian difference here that makes signing work here, but not there.
(In reply to Miklos Vajna from comment #6) > [...] > Could you please check: > > 1) In XMLSignature_NssImpl::generate(), when we do the xmlSecDSigCtxSign() > call that is the actual signing, do you get an error? > > 2) If you get an error, then ideally we get error details via the xmlsec log > callback, can you check if errorCallback() gets called? If so, do we get any > details there, why the signing fails? Indeed when XMLSignature_NssImpl::generate() calls xmlSecDSigCtxSign() the errorCallback() is being triggered. It outputs these lines to the shell: warn:xmlsecurity.xmlsec:394210:394210:xmlsecurity/source/xmlsec/errorcallback.cxx:54: x509vfy.c:480: xmlSecNssX509StoreVerifyCert() '' '' 71 'subject="E=MyName@my_domain.org,CN=My Name"; reason=-8179' warn:xmlsecurity.xmlsec:394210:394210:xmlsecurity/source/xmlsec/errorcallback.cxx:54: keys.c:1346: xmlSecKeysMngrGetKey() '' '' 45 'details=NULL' warn:xmlsecurity.xmlsec:394210:394210:xmlsecurity/source/xmlsec/errorcallback.cxx:54: xmldsig.c:822: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL' warn:xmlsecurity.xmlsec:394210:394210:xmlsecurity/source/xmlsec/errorcallback.cxx:54: xmldsig.c:537: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' ' warn:xmlsecurity.xmlsec:394210:394210:xmlsecurity/source/xmlsec/errorcallback.cxx:54: xmldsig.c:301: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' ' xmlSecDSigCtxSign() returns -1. > Thanks. FWIW I'm on openSUSE Leap 15.5, I guess there is some openSUSE vs > Debian difference here that makes signing work here, but not there. I've ran the following build on an openSUSE-15.5 (LEAP) live system and got the same problem. https://download.documentfoundation.org/libreoffice/stable/24.2.4/rpm/x86_64/LibreOffice_24.2.4_Linux_x86-64_rpm.tar.gz Same with builds from the LO-24.2 bibisect repo on openSUSE-15.5. Only the LibreOffice-24.2.4 build which comes with openSUSE-15.5 works, but I guess it's simply because it uses xmlsec-1.2.37 from openSUSE-15.5 instead of an internal xmlsec-1.3.x. Used live image: https://download.opensuse.org/distribution/leap/15.5/live/openSUSE-Leap-15.5-KDE-Live-x86_64-Build13.217-Media.iso Linux distros shipping xmlsec >= 1.3 still seem to be very rare. Even openSUSE-Tumbleweed-20240705 currently remains on xmlsec-1.2.x. But fortunately the current Manjaro-24.0.3 live image comes with xmlsec-1.3.4 and has LibreOffice-24.2.4: https://download.manjaro.org/kde/24.0.3/manjaro-kde-24.0.3-minimal-240702-linux69.iso Test result: ODF X.509 signing is broken on Manjaro 24.0.3 (240702), using Manjaros LibreOffice build.
Aha, that's interesting, thanks. 1) This doesn't seem to be a distro difference. 2) The signing fails in xmlSecNssX509StoreVerifyCert(), one could argue that this is a bug in xmlsec, given that we specify XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS during signing. Do you want to take this to xmlsec upstream? The logs in this bug may be enough of a hint to show that cert verify happens in the no-verify case. 3) Do you understand why the cert verify fails in your case? When you import the result of create-certs.sh, do you perform the import correctly, as in you import both the CA chain & the signing cert? When you import the CA chain, do you mark it as trusted on the Firefox UI? Probably either 2) and 3) resolves the problem, just at different levels.
Created attachment 195198 [details] SAL_LOG="+INFO+WARN" output (In reply to Miklos Vajna from comment #8) > [...] > 3) Do you understand why the cert verify fails in your case? When you import > the result of create-certs.sh, do you perform the import correctly, as in > you import both the CA chain & the signing cert? When you import the CA > chain, do you mark it as trusted on the Firefox UI? Nice guess! :-) Indeed, when I mark the root and intermediate certificate from create-certs.sh as trusted in Thunderbird (for mail and websites) then ODF signing works. OK I really didn't thought of that. I rarely use X.509 in Thunderbird. And when I do, I use a certificate from https://www.cacert.org/ whose X.509 CA isn't trusted by default in Mozilla software. But Thunderbird never needed me to mark the CACert CA as trusted. Signing and encrypting mails always worked fine without. And so did ODF signing in LibreOffice < 24.2. Thunderbird doesn't make it very convenient to mark the X.509 CA of the users own certificate as trusted. At least I see no direct way from my own certificate in Thunderbird to the trust dialog for the CA. Instead I've had to lookup the CA name in my own certificate and then search trough the long list of CAs. Thunderbird also doesn't notify the user to trust the CA when importing an own certificate. And as said, Thunderbird itself doesn't require CA trust, so that's consistent inside Thunderbird. Conclusion: In LibreOffice 24.2 I can still sign PDF files with X.509 certificates without having the CA trusted. So that's an inconsistency. And if ODF signing shall stay the way it's now, it should get a proper error dialog informing the user about the missing CA trust. And additionally it might be worth a thought, to look for a way to make it easier to mark the own certificates CA as trusted in Thunderbird/Firefox/Seamonkey. Unfortunately I'm currently too busy to care further about this bug. Same goes for an upstream bug at xmlsec. This bug was more of a side discovery and I don't really use that feature. Sorry! But I've still attached the requested SAL_INFOs, in case they are of any use.
Ah, with the additional description, can confirm this new behaviour.
I researched this a bit, and it seems that you're right Moritz, it's not common to require that the CA is trusted at signature creation time. Could you please report this at xmlsec upstream? The ideal would be to get this fixed there and we just update xmlsec in LO. Failing that, a compromise would be to get xmlsec to at least not do this in the XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS case. The usage of that flag is discouraged by upstream (they say it should be a debug option in the long term and LO should not use it by default, but it's the behavior we inherited from OOo), but that would give us a way to have the behavior we want without changing default xmlsec behavior. Thanks.
Just found something by the way: On Windows the X.509 ODF signing may be completely broken. I imported a certificate into the Windows certmgr (mscrypt). And the CA is in the folder with trusted CAs in the Windows certmgr. But I can't sign an ODF with current LO master. I didn't do a bisect, but the latest 7.6 works fine. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\mscng\x509vfy.c:421: xmlSecMSCngX509StoreVerifySubject() '' '' 71 'details=CertVerifySubjectCertificateContext: CERT_STORE_SIGNATURE_FLAG' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\mscng\x509vfy.c:476: xmlSecMSCngX509StoreContainsCert() '' '' 71 'details=xmlSecMSCngX509StoreVerifySubject' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\mscng\x509vfy.c:549: xmlSecMSCngX509StoreVerifyCertificateOwn() '' 'xmlSecMSCngX509StoreContainsCert' 1 ' ' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\mscng\x509vfy.c:797: xmlSecMSCngX509StoreVerifyCertificate() '' 'xmlSecMSCngX509StoreVerifyCertificateOwn' 1 ' ' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\mscng\x509vfy.c:931: xmlSecMSCngX509StoreVerify() 'x509-store' 'xmlSecMSCngX509StoreVerifyCertificate' 1 ' ' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\keys.c:1344: xmlSecKeysMngrGetKey() '' '' 45 'details=NULL' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\xmldsig.c:822: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\xmldsig.c:537: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' ' Cannot find object or property. warn:xmlsecurity.xmlsec:9484:10996:xmlsecurity/source/xmlsec/errorcallback.cxx:54: ..\src\xmldsig.c:301: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' ' Cannot find object or property.
(In reply to Moritz Duge (allotropia) (a.k.a. kolAflash) from comment #12) > Just found something by the way: > > On Windows the X.509 ODF signing may be completely broken... I confirm this on Windows 10 x86_64 (10.0 build 14393) with version 24.8.4.2 Is there a need to create a separate bug-report? What other useful information can I provide?
As I understand, the current state is that libxmlsec upstream changed their behavior, so signing with an untrusted signing cert used to work, and now it does not. It's not entirely clear if this is wanted or not. And nobody filed an libxmlsec upstream issue to ask the maintainer if this is intentional or not. You can do that at https://github.com/lsh123/xmlsec/
(In reply to alex.ilmar4spam from comment #13) > (In reply to Moritz Duge (allotropia) (a.k.a. kolAflash) from comment #12) > > [...] > > On Windows the X.509 ODF signing may be completely broken... > [...] > Is there a need to create a separate bug-report? What other useful > information can I provide? If you have some spare time, you may try to find the exact commit which broke the behavior on Windows. LibreOffice has a repositories of binary builds to conduct such tests. It's called Bibisect. (binary bisect) https://wiki.documentfoundation.org/QA/Bibisect Use Git to clone the LibreOffice-24.2 for Window Bibisect repo. https://bibisect.libreoffice.org/win64-24.2 First test the binary commit based on the bad commit bfd479abf I found. Just grep for it in the Git log. The test the previous binary commit git log | grep -C10 bfd479abf If that's not the bad commit, you may do a full bisect testing. https://en.wikipedia.org/wiki/Bisection_(software_engineering) If Windows is also broken by commit bfd479abf then I'd say we handle it in this ticket. If another commit is the bad commit, you may open a new ticket. Thanks! (In reply to Miklos Vajna from comment #14) > [...] nobody filed > an libxmlsec upstream issue to ask the maintainer if this is intentional or > not. You can do that at https://github.com/lsh123/xmlsec/ I just filed an upstream issue. https://github.com/lsh123/xmlsec/issues/866 I'm just guessing, that you have far better insight than I do to drive the upstream issue forward.
> I just filed an upstream issue. Thanks. Let's provide the info Aleksey is asking, then I hope we can track this down over there.
OK, based on input from upstream, this can be fixed by explicitly disabling cert verify while sign.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1817760f56b74e47120c1b4d7641fbaebcf378ad tdf#161872 xmlsecurity nss: don't require trusted signing certs It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ec9dbbe288ccb759ed95533fb849dac8a65c4a6b tdf#161872 xmlsecurity mscrypt: don't require trusted signing certs It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #19) > [...] > https://git.libreoffice.org/core/commit/ec9dbbe288ccb759ed95533fb849dac8a65c4a6b > tdf#161872 xmlsecurity mscrypt: don't require trusted signing certs Confirming. This and the previous commit fixed it on Linux and also on MS-Windows 11. So this also seems to fix the comment 12 MS-Windows problem. @ilmarranen Can you confirm it's working again on Windows?
P.S. @Miklos Should this be backported to 24.8.0 and 25.2.0 ? Looks like both patches apply seamlessly.
I see Xisco already did libreoffice-25-2 backports.
What about libreoffice-24-8 ? (I can't do it, I don't have author-push permissions for cherry-pick)
(In reply to Moritz Duge (allotropia) (a.k.a. kolAflash) from comment #20) > Confirming. This and the previous commit fixed it on Linux and also on > MS-Windows 11. > > So this also seems to fix the comment 12 MS-Windows problem. > > @ilmarranen > Can you confirm it's working again on Windows? I get very strange results (probably because of my low qualification), now I will try to explain: 1. I tested the daily build (I don't have a configured LibreOffice build environment yet) BEFORE commits 1817760f and ec9dbbe2, namely a8ec21adf255b70bb6eeb0a1717190df303d8b26 - signing with an untrusted certificate does NOT work 2. I tested the daily build AFTER commits 1817760f and ec9dbbe2, namely 7a9e303d0ffad7b83beccfe1918f962d2de04a37 - signing with an untrusted certificate works. Thus, I confirm that the problem from the original message seems to be solved on Windows as well. However, the error for which I wrote the comment 13 is apparently different: in the release version 24.8.4.2 with commit-hash bb3cfa12c, signing with an X.509 certificate for ODF does not work, but the certificate IS TRUSTED. I continue trying to run bibisect for my case (I spent a lot of time creating a test environment, because testing on production is impossible). However, it is possible that this does not make sense, since in versions 25.x I no longer record this error. I will continue searching for educational purposes)). Please tell me how to find a backport from comment 22 (daily build? commit?) ? This will definitely help me if the backport for 24.8 is done.
> What about libreoffice-24-8 ? Let's deal with that once the 25.2 backports are in. > However, the error for which I wrote the comment 13 is apparently different: in the release version 24.8.4.2 with commit-hash bb3cfa12c, signing with an X.509 certificate for ODF does not work, but the certificate IS TRUSTED. Probably best to track that in a different bug then: the scope of this bug is the case when signing works fine, just fails when you don't trust the sign cert. Thanks.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/723ecfa63f5218b2f06f0a807b56869b80a19fe2 tdf#161872 xmlsecurity nss: don't require trusted signing certs It will be available in 25.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/b9c8f8a0fb0f56fc91b4882afcc06041796f1ca3 tdf#161872 xmlsecurity mscrypt: don't require trusted signing certs It will be available in 25.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/83a67cfbde00887b5e158e1026d0b6c2cadff3b4 tdf#161872 xmlsecurity mscrypt: don't require trusted signing certs It will be available in 24.8.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/3166d5fc732a812ca8f8c296de285dbeee6dcb1e tdf#161872 xmlsecurity nss: don't require trusted signing certs It will be available in 24.8.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-24-8-5": https://git.libreoffice.org/core/commit/e7405fe114fcb81073f8e875da0711e38fcaa233 tdf#161872 xmlsecurity nss: don't require trusted signing certs It will be available in 24.8.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-24-8-5": https://git.libreoffice.org/core/commit/c61a5f5657bc259accc2d05d9c628050db2153c1 tdf#161872 xmlsecurity mscrypt: don't require trusted signing certs It will be available in 24.8.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.