forked from amazingfate/loongoffice
d95ab8d3a3
Once the signing key is taken from the matching SfxViewShell (not yet done), signing with a certificate specified via initializeForRendering() failed with: warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx:330: X509Certificate_NssImpl::getPrivateKey() cannot find private key warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:812: Can't get the private key from the certificate. warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: keys.c:1347: xmlSecKeysMngrGetKey() '' '' 45 'details=NULL' warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:822: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL' warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:537: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' ' warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:301: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' ' The trouble was that we wanted to keep the private key in-memory, presumably because initially the whole NSS database was in-memory for the LOK case. This was changed in commit 87eec1b90b6ecd83455f09168430c23f73c25c86 (NSS: create a temporary database instead of in-memory, 2018-12-31), so there is no problem with a not-in-memory private key anymore. Note that the problematic codepath was only triggered when first the certificate chooser was ran and only then we signed. So the testcase also gets the cert flags before signing, otherwise the test would succeed even without the fix. Change-Id: I5086b205c91b630ddd343c0eb91bd9e63b3ea238 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173892 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins