... and use it in the new experimental ODF encryption mode.
https://www.w3.org/TR/xmlenc-core1/#sec-AES-GCM
Unfortunately it turned out that NSS PK11_CipherOp() does not work with
CKM_AES_GCM because it is initialized with "context->multi = PR_FALSE"
in sftk_CryptInit(), so the one-step functions PK11_Encrypt() and
PK11_Decrypt() have to be used.
NSS 3.52 also changed a parameter struct definition - see
https://fedoraproject.org/wiki/Changes/NssGCMParams - which is not a
problem for RHEL or SUSE system NSS since those are rebased, but it
is likely a problem for less well maintained Ubuntu LTS, so use
the old struct definition which evidently still works with NSS 3.94.
NSS 3.52 also added a new PK11_AEADOp() API but it looks like this
doesn't support incremental encryption either.
Change-Id: Ibd4a672db74b65b1218926ba35ff8d2f70444c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160505
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Missed a special case in previous commit, in case the input is
completely empty and PK11_DigestFinal() doesn't see a problem with it,
aResult could be empty too.
Change-Id: I8ea900774ae390857307ec5bab38876bead6bc86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160441
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
If this function returns null, storing a document will proceed without
reporting an error to the user, and lose all the data.
Change-Id: I0f9fd53702321e7997b28e12eb5bed3349bbcc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160435
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
new plugin to look for class fields that are always cast to some
subtype, which indicates that they should probably just be declared to
be that subtype.
Perform one of the suggested improvements in xmlsecurity/
Change-Id: Ia68df422c37f05cbcf9c02ba5d0853f8eca4f120
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159063
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As a complementer to clang-tidy-12 --checks="-*,misc-unused-using-decls"
Pros:
- simple, fast!
- finds some more unused declarations, somehow
- works on non-linux specific parts of the code
- clang-tidy (for me) trips on files with external headers, this does not
Change-Id: If2db989114ac5c2841ed2e89ff7bd7a9e419f567
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150612
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
And simplify the latter, to always use "CDATA" type (as the former did).
"CDATA" was used in all cases but one, where an empty string was used.
Change-Id: I1b3bfae40e29628e4094d9a6e58a69a66865874c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I3d9bd77093d2e6376717d27f105e72ff5a919fe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...like in other code accessing X509Certificate_NssImpl. (See the upcoming
commit introducing loplugin:unocast on why such dynamic_casts from UNO types are
dangerous.
Change-Id: I65c8380ef0c3ab34a41142639e0e6fbfb4154b27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144510
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
CentOS 7 system NSS defaults to legacy "dbm:" DB.
test_desktop_lib.cxx:2830:Assertion
Test name: DesktopLOKTest::testInsertCertificate_PEM_ODT
equality assertion failed
- Expected: 1
- Actual : 2
The problem is that getPrivateKey() doesn't work:
warn:xmlsecurity.xmlsec:624712:624712:xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:824: Can't get the private key from the certificate.
In this function, there is a check for trust flags, and the CERTDB_USER
flag is not set, which causes the failure.
The certificate was inserted here and the trust flags were set; this
does write something to cert8.db and it's not clear why it doesn't work
(if this call is omitted with the "sql:" backend, the test fails with
NOTVALIDATED = 4 - as expected).
Oddly enough, while PK11_FindPrivateKeyFromCert() fails, there's another
function PK11_FindKeyByDERCert() that does appear to work, so call it as
a fallback.
Change-Id: I9821966a086574374f4f6df0ac5db2f7376fe742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133576
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The problem is that in SecurityEnvironment_NssImpl::insertPrivateKey()
the PK11_ImportDERPrivateKeyInfoAndReturnKey() fails because
NSC_CreateObject() finds a slot->needLogin = 1.
This value is set during the first NSS_InitReadWrite() in
nsscrypto_initialize(), usually this fails, and the fallback path ends
up calling PK11_InitPin(), which sets slot->needLogin = 0, whereas
running with uid 0, the first call succeeds and PK11_InitPin() wasn't
called.
This causes test failures in CppunitTest_desktop_lib
testInsertCertificate_PEM_ODT.
Change-Id: I302ff17493f9b4d74ceae9da6831a5af87d7f622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133575
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
x509.h includes cert.h. But that doesn't know of LO using
xmlsecurity/source/xmlsec/nss/nssrenam.h, which has a "#define
CERT_DecodeDERCertificate __CERT_DecodeDERCertificate". So the PCH
doesn't know of this rename and the compiler fails.
move the include line into the file that needs it and the --enable-pch=full
build works ok
Change-Id: I247bd219cf47964490ded439ad51bd8e8e120c48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127744
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
We have two environments where the signature and the stream bytes are
the same, still in one case the signature verification succeeds and in
the other case the hash doesn't match.
Log the signature as parsed into a DOM node (recursively), just case
something goes wrong during extracting a single signature from the
signatures list XML.
Change-Id: I54af71fdeb63d8ef44342f106746f938fa51f29a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127991
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
We only get:
warn:xmlsecurity.xmlsec:32272:32272:xmlsecurity/source/xmlsec/errorcallback.cxx:53: digests.c:226: xmlSecNssDigestVerify() 'sha1' '' 12 'data and digest do not match'
when one of the XML streams have a bad hash. Add some logging to help
figuring out (without a debugger) which stream is at fault.
Change-Id: Ib5f39df87bcdaaac1a21eb560c8f775c42a4079f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127885
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
It turns out that the 2 backends NSS and MS CryptoAPI generate different
string representations of the same Distinguished Name in at least one
corner case, when a value contains a quote " U+0022.
The CryptoAPI function to generate the strings is:
CertNameToStr(..., CERT_X500_NAME_STR | CERT_NAME_STR_REVERSE_FLAG, ...)
This is documented on MSDN:
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certnametostra#CERT_X500_NAME_STR
NSS appears to implement RFC 1485, at least that's what the internal
function is named after, or perhaps one of its several successor RFCs
(not clear currently if there's a relevant difference).
This is now causing trouble if a certificate with such a DN is used in a
signature, created on WNT but then verified on another platform, because
commit 5af5ea893b
introduced consistency checks that compare the DNs that occur as strings
in META-INF/documentsignatures.xml:
xmlsecurity/source/helper/xmlsignaturehelper.cxx:672: X509Data cannot be parsed
The reason is that in XSecController::setX509Data() the value read from
the X509IssuerSerial element (a string generated by CryptoAPI) doesn't
match the value generated by NSS from the certificate parsed from the
X509Certificate element, so these are erroneously interpreted as 2
distinct certificates.
Try to make the EqualDistinguishedNames() more flexible so that it can
try also a converted variant of the DN.
(libxmlsec's NSS backend also complains that it cannot parse the DN:
x509vfy.c:607: xmlSecNssX509NameRead() '' '' 12 'invalid data for 'char': actual=34 and expected comma ',''
but it manages to validate the signature despite this.)
Change-Id: I4f72900738d1f5313146bbda7320a8f44319ebc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124287
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Michael Stahl