summaryrefslogtreecommitdiff
path: root/xmlsecurity
AgeCommit message (Collapse)AuthorFilesLines
2021-10-29xmlsecurity: some Distinguished Names are less equal than othersMichael Stahl8-20/+211
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 5af5ea893bcb8a8eb472ac11133da10e5a604e66 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.) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124287 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit e63611fabd38c757809b510fbb71c077880b1081) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124196 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 3dfe381032fc61ea31106f103dee9db8277d4d25) Change-Id: I4f72900738d1f5313146bbda7320a8f44319ebc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124421 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-21xmlsecurity: fix test failing because NSS policy forbids SHA1Michael Stahl4-0/+43
With Fedora's nss-3.71.0-1.fc34.x86_64 there is the problem that 8 tests including testODFGood in CppunitTest/xmlsecurity_signing fail because the crypto policy disallows SHA1 for signatures. Apparently this particular policy bit was added in NSS 3.59: https://bugzilla.mozilla.org/show_bug.cgi?id=1670835 For signatures, maybe it's not a good idea to override system policy for product builds, so do it locally in the tests, at least for now. If similar problems turn up for encrypted documents in the future, that should be fixed in product builds too of course, as encrypted documents must always be decryptable. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123768 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 51e82016e8783a452fe5f7921d12c1bf20bfd6b5) xmlsecurity: fix --without-system-nss usage of NSS_SetAlgorithmPolicy The problem with commit ff572d9222ec16ffd679ae907a0bf4a8900265e1 is that it's using the wrong library; NSS_SetAlgorithmPolicy is actually in libnssutil3.so. This causes a linking problem when upgrading the internal NSS to a version that has NSS_USE_ALG_IN_ANY_SIGNATURE. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123819 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 395c0c0bbaceadf909e0189af99c6358487c7978) Change-Id: I4f634cf5da1707fb628e63cd0cdafebdf4fc903f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123841 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-21test: upgrade test NSS database from dbm: to sql:Michael Stahl6-6/+13
Fedora nss-3.69.0-1.fc34.x86_64 and Debian libnss3:amd64 2:3.70-1 no longer support the old BerekelyDB databases, so convert them to the new SQLite format for the benefit of --with-system-nss builds. This worked to do the upgrade: > certutil -N -d sql:test/new --empty-password > LD_LIBRARY_PATH=instdir/program workdir/UnpackedTarball/nss/dist/out/bin/certutil --merge -d sql:test/new --source-dir dbm:test/signing-keys Builds would fail running tests added in commit 40d70d427edddb589eda64fafc2e56536953d274 signing.cxx:551:Assertion Test name: testODFX509CertificateChain::TestBody equality assertion failed - Expected: 0 - Actual : 1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123586 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 907784ccce7bd8b5121888cff7f5723a55d35358) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123643 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 7b4b03b9cf21ecd11bc82da5f29c4ff91ad242c9) Change-Id: I00aa20703e117ebf583c3331b84e966c2cfc78cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123840 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-21xmlsecurity: fix new tests on WNTMichael Stahl4-9/+340
Tests added in commit 40d70d427edddb589eda64fafc2e56536953d274 don't actually run on WNT but that wasn't obvious because commit 149df1fec6472e30582162e17e04c75aee91d26a prevented running them in Jenkins on master, they failed only in the libreoffice-7-1 backport. xmlsecurity/qa/unit/signing/signing.cxx(631) : error : Assertion Test name: testODFDoubleX509Certificate::TestBody assertion failed - Expression: (nActual == SignatureState::NOTVALIDATED || nActual == SignatureState::OK) - 2 This is an oddity where NSS claims the signature in the document is valid but CryptoAPI claims it is invalid; the hashes passed into the validation functions are the same. Just allow BROKEN as an additional result value on WNT. xmlsecurity/qa/unit/signing/signing.cxx(550) : error : Assertion Test name: testODFX509CertificateChain::TestBody equality assertion failed - Expected: 0 - Actual : 1 The problem here is that with NSS the tests use a custom NSS database in test/signing-keys so we need to make these certificates available for CryptoAPI too. The following one-liner converts the NSS database to a PKCS#7 that can be loaded by CrytpAPI: > openssl crl2pkcs7 -nocrl -certfile <(certutil -d sql:test/signing-keys -L | awk '/^[^ ].*,[^ ]*,/ { printf "%s", $1; for (i = 2; i < NF; i++) { printf " %s", $i; } printf "\n"; }' | while read name; do certutil -L -d sql:test/signing-keys -a -n "${name}" ; done) > test/signing-keys/test.p7b Then one might naively assume that something like this would allow these certificates to be added temporarily as trusted CAs: + HCERTSTORE hRoot = CertOpenSystemStoreW( 0, L"Root" ) ; + HCERTSTORE const hExtra = CertOpenStore( + CERT_STORE_PROV_FILENAME_A, + PKCS_7_ASN_ENCODING | X509_ASN_ENCODING, + NULL, + CERT_STORE_OPEN_EXISTING_FLAG | CERT_STORE_READONLY_FLAG, + path); + if (hExtra != NULL && hRoot != NULL) + { + BOOL ret = CertAddStoreToCollection( + hRoot, + hExtra, + CERT_PHYSICAL_STORE_ADD_ENABLE_FLAG, + 0); + SAL_DEBUG("XXX hExtra done " << ret); + } There is no error from this, but it doesn't work. Instead, check if CertGetCertificateChain() sets the CERT_TRUST_IS_UNTRUSTED_ROOT flag and then look up the certificate manually in the extra PKCS#7 store. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123667 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 7d664ec788acdc378506a7ff8b1120cea24a6770) Change-Id: Ic9865e0b5783211c2128ce0327c4583b7784ff62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123839 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-11xmlsecurity: add tests for multiple X509Data/X509CertificateMichael Stahl6-0/+110
Change-Id: If50ae8156f81c1053aa8fbfc3148da64bb8e1442
2021-10-11xmlsecurity: add test for timestampsMichael Stahl2-0/+24
Change-Id: I6ce64ca7c59639684779144ed0ed8d36c4aca32b
2021-04-13Fixup xmlsecurity testThorsten Behrens1-3/+3
Change-Id: I616867dbf79a85671d04bd31fac5cb592b5beaaf
2021-03-31xmlsecurity: replace OOXMLSecParser implementationMichael Stahl2-234/+1311
This is similar to 12b15be8f4f930a04d8056b9219ac969b42a9784 and following commits, but OOXMLSecParser has some differences to XSecParser, such as using a ds:Manifest, and requires a couple extra namespaces. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113381 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit cc1d19f7bbaefa5fb22ebd1344112755068b93c9) Change-Id: I56e39d9609db8fcad50ca1632ff482c1f0a30ff5
2021-03-31xmlsecurity nss: fix OOXML signing with ECDSA keyMiklos Vajna3-3/+57
Reviewed-on: https://gerrit.libreoffice.org/54779 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 6b1b8ef51b752f9711d6581283d6c515d3c50d9b) Change-Id: Id2b59887fcd69e294a6d9db17ec0446615054ecc
2021-03-29Also fix the generated test certs + generator script to avoid expiredMiklos Vajna3-3/+3
certs for a while (.db files generated with Firefox 57.0). Reviewed-on: https://gerrit.libreoffice.org/56123 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 71198fe7d9539859883b6226738fbea52a08a5c4) Change-Id: I30e1b13454cc45ead7605d076e8e24984ae186c1
2021-03-29xmlsecurity: improve handling of multiple X509Data elementsMichael Stahl19-197/+641
Combine everything related to a certificate in a new struct X509Data. The CertDigest is not actually written in the X509Data element but in xades:Cert, so try to find the matching entry in XSecController::setX509CertDigest(). There was a confusing interaction with PGP signatures, where ouGpgKeyID was used for import, but export wrote the value from ouCertDigest instead - this needed fixing. The main point of this is enforcing a constraint from xmldsig-core 4.5.4: All certificates appearing in an X509Data element MUST relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111254 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 9e82509b09f5fe2eb77bcdb8fd193c71923abb67) xmlsecurity: improve handling of multiple certificates per X509Data It turns out that an X509Data element can contain an arbitrary number of each of its child elements. How exactly certificates of an issuer chain may or should be distributed across multiple X509Data elements isn't terribly obvious. One thing that is clear is that any element that refers to or contains one particular certificate has to be a child of the same X509Data element, although in no particular order, so try to match the 2 such elements that the parser supports in XSecController::setX509Data(). Presumably the only way it makes sense to have multiple signing certificates is if they all contain the same key but are signed by different CAs. This case isn't handled currently; CheckX509Data() will complain there's not a single chain and validation of the certificates will fail. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111500 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 5af5ea893bcb8a8eb472ac11133da10e5a604e66) xmlsecurity: add EqualDistinguishedNames() Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111545 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 1d3da3486d827dd5e7a3bf1c7a533f5aa9860e42) xmlsecurity: avoid exception in DigitalSignaturesDialog::getCertificate() Fallback to PGP if there's no X509 signing certificate because CheckX509Data() failed prevents the dialog from popping up. To avoid confusing the user in this situation, the dialog should show no certificate, which is already the case. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111664 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 90b725675c2964f4a151d802d9afedd8bc2ae1a7) xmlsecurity: fix crash in DocumentDigitalSignatures::isAuthorTrusted() If the argument is null. This function also should use EqualDistinguishedNames(). Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111667 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit ca98e505cd69bf95d8ddb9387cf3f8e03ae4577d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111910 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit a1cf770c2d7ca3e153e0b1f01ddcc313bc2bed7f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113058 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Change-Id: I9633a980b0c18d58dfce24fc59396a833498a77d
2021-03-29libxmlsec: drop not needed xmlsec1-customkeymanage.patch.1Miklos Vajna1-36/+0
This was added in commit ebd1b95bb5f9235d1dba1b840fd746c9b53320d2 (INTEGRATION: CWS xmlsec08 (1.1.2); FILE ADDED; 2005-03-10) without any real commit message to explain why this is necessary. system-xmlsec (not containing this patch) works fine for our XML signing purposes with software certificates, and just recently I learned that even hardware-based certificates work fine without this patch, so it can go away. I assume this was a refactor to allow some new feature as a next step, but that feature was never implemented. [ Committer's note: this xmlsec1-customkeymanage.patch.1 breaks the test SigningTest::testXAdESNotype(): In xmlSecNssKeyDataX509VerifyAndExtractKey(), code is added to extract the *private* key of the certificate; upstream only extracts the public key. Later this causes a key requirement check in xmlSecKeysMngrGetKey() to succeed which would otherwise fail, and the certificate to remain uncleared. Then xmlSecKeyInfoNodeWrite() writes the certificate into the KeyInfo element, where it was previously read from, so it is duplicated and LO's CheckX509Data() fails because of 2 signing certificates. ] Reviewed-on: https://gerrit.libreoffice.org/55296 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit f06004c03bbd076767a570180b7fc239064713e6) Change-Id: I31639230483cd34b14b35fd41b4fcd8284476138
2021-03-29Fix commentsSamuel Mehrbrodt1-1/+1
Signature lines is no longer ooxml specific Change-Id: I092dbc31b30d30bf68b4cb733cb7cb8520c99738 Reviewed-on: https://gerrit.libreoffice.org/55058 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 8fe7198466011a411b46295cb646338b8745308c)
2021-03-29clang-format ooxmlsecexporter.cxxMichael Stahl1-74/+129
Change-Id: I3faa33c98ec56197a1528f443c3850c70e171c4b
2021-03-29xmlsecurity: ignore elements in ds:Object that aren't signedMichael Stahl4-90/+221
Change-Id: I2e4411f0907b89e7ad6e0185cee8f12b600515e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111253 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 2bfa00e6bf4b2a310a8b8f5060acec85b5f7a3ce) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111909 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 94ce59dd02fcfcaa1eb4f195b45a9a2edbd58242)
2021-03-29xmlsecurity: XSecParser confused about multiple timestampsMichael Stahl7-78/+63
LO writes timestamp both to dc:date and xades:SigningTime elements. The parser tries to avoid reading multiple dc:date, preferring the first one, but doesn't care about multiple xades:SigningTime, for undocumented reasons. Ideally something should check all read values for consistency. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111160 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 4ab8d9c09a5873ca0aea56dafa1ab34758d52ef7) xmlsecurity: remove XSecController::setPropertyId() Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111252 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit d2a345e1163616fe3201ef1d6c758e2e819214e0) Change-Id: Ic018ee89797a1c8a4f870ae102af48006de930ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111908 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit abe77c4fcb9ea97d9fff07eaea6d8863bcba5b02)
2021-03-29xmlsecurity: replace XSecParser implementationMichael Stahl2-346/+1341
Implement Namespaces in XML and follow xmldsig-core and XAdES schemas. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110833 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 12b15be8f4f930a04d8056b9219ac969b42a9784) xmlsecurity: move XSecParser state into contexts Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111158 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 59df9e70ce1a7ec797b836bda7f9642912febc53) xmlsecurity: move XSecParser Reference state into contexts Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111159 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit cfeb89a758b5f0ec406f0d72444e52ed2f47b85e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111907 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit ad5930e87e788780a255523f106deb1dde5d7b37) Change-Id: I03537b51bb757ecbfa63a826b38de543c70ba032
2021-03-29expand out some namespace aliases [xmlsecurity/source/helper]Noel Grandin4-123/+107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94093 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit 943fbfad668da76f7d0ebd4f4d8cdd67224d2f01) plus one line in xsecverify.cxx from: commit f59d9e7ea09482c2e9e5f52a8d0445e4cebc3df5 Author: Noel Grandin <noel.grandin@collabora.co.uk> AuthorDate: Fri Apr 3 15:53:49 2020 +0200 new loplugin:unusedvariableplus a particularly aggressive checker, which is why it is off by default Change-Id: I5fdb554a1b116824843f35645bc1cea3ca91e0f2
2021-03-29css::security::DocumentSignatureInformation::SignatureTime is 32 bitStephan Bergmann1-1/+1
...and has always represented the time of day in 100th of seconds. When tools::Time had been changed to 64 bit nanoseconds in 9830fd36dbdb72c79703b0c61efc027fba793c5a "date/time IDL datatypes incompatible change", conversion between the two has apparently been forgotten, so that CppunitTest_desktop_lib under (new-in-Clang) -fsanitize=implicit-signed-integer-truncation failed with > xmlsecurity/source/component/documentdigitalsignatures.cxx:536:38: runtime error: implicit conversion from type 'sal_Int64' (aka 'long') of value 192536379741069 (64-bit, signed) to type '::sal_Int32' (aka 'int') changed the value to 1585795981 (32-bit, signed) > #0 in DocumentDigitalSignatures::ImplVerifySignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, DocumentSignatureMode) at xmlsecurity/source/component/documentdigitalsignatures.cxx:536:38 (instdir/program/libxmlsecurity.so +0x488319) > #1 in DocumentDigitalSignatures::verifyDocumentContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) at xmlsecurity/source/component/documentdigitalsignatures.cxx:296:12 (instdir/program/libxmlsecurity.so +0x484ea6) > #2 in non-virtual thunk to DocumentDigitalSignatures::verifyDocumentContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) at xmlsecurity/source/component/documentdigitalsignatures.cxx (instdir/program/libxmlsecurity.so +0x4890fa) > #3 in SfxObjectShell::ImplAnalyzeSignature(bool, com::sun::star::uno::Reference<com::sun::star::security::XDocumentDigitalSignatures> const&) at sfx2/source/doc/objserv.cxx:1368:47 (instdir/program/libsfxlo.so +0x3866a04) > #4 in SfxObjectShell::ImplGetSignatureState(bool) at sfx2/source/doc/objserv.cxx:1397:74 (instdir/program/libsfxlo.so +0x3869118) > #5 in SfxObjectShell::GetDocumentSignatureState() at sfx2/source/doc/objserv.cxx:1575:12 (instdir/program/libsfxlo.so +0x3863e57) > #6 in SfxObjectShell::CheckForBrokenDocSignatures_Impl() at sfx2/source/doc/objmisc.cxx:974:38 (instdir/program/libsfxlo.so +0x3812535) > #7 in SfxObjectShell::CheckSecurityOnLoading_Impl() at sfx2/source/doc/objmisc.cxx:924:5 (instdir/program/libsfxlo.so +0x38120bc) > #8 in SfxObjectShell::FinishedLoading(SfxLoadedFlags) at sfx2/source/doc/objmisc.cxx:1072:9 (instdir/program/libsfxlo.so +0x3818a89) > #9 in SwDocShell::LoadingFinished() at sw/source/uibase/app/docsh.cxx:1200:5 (instdir/program/libswlo.so +0xcfd4f08) > #10 in SwDocShell::Load(SfxMedium&) at sw/source/uibase/app/docshini.cxx:582:13 (instdir/program/libswlo.so +0xd091a39) > #11 in SfxObjectShell::LoadOwnFormat(SfxMedium&) at sfx2/source/doc/objstor.cxx:3053:20 (instdir/program/libsfxlo.so +0x3895e54) > #12 in SfxObjectShell::DoLoad(SfxMedium*) at sfx2/source/doc/objstor.cxx:725:40 (instdir/program/libsfxlo.so +0x389bdd5) > #13 in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/sfxbasemodel.cxx:1795:36 (instdir/program/libsfxlo.so +0x3a40e1e) > #14 in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) at sfx2/source/view/frmload.cxx:688:28 (instdir/program/libsfxlo.so +0x40c30c0) > #15 in framework::LoadEnv::impl_loadContent() at framework/source/loadenv/loadenv.cxx:1149:37 (instdir/program/libfwklo.so +0x1520131) > #16 in framework::LoadEnv::startLoading() at framework/source/loadenv/loadenv.cxx:383:20 (instdir/program/libfwklo.so +0x1510b16) > #17 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/loadenv/loadenv.cxx:169:14 (instdir/program/libfwklo.so +0x150c7c8) > #18 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/services/desktop.cxx:619:12 (instdir/program/libfwklo.so +0x166f1ce) > #19 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/services/desktop.cxx (instdir/program/libfwklo.so +0x166f3da) > #20 in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at unotest/source/cpp/macros_test.cxx:50:60 (workdir/LinkTarget/CppunitTest/../Library/libunotest.so +0x8f176) > #21 in DesktopLOKTest::loadDoc(char const*, LibreOfficeKitDocumentType) at desktop/qa/desktop_lib/test_desktop_lib.cxx:215:19 (workdir/LinkTarget/CppunitTest/libtest_desktop_lib.so +0xf2ca0) > #22 in DesktopLOKTest::testGetSignatureState_Signed() at desktop/qa/desktop_lib/test_desktop_lib.cxx:2254:37 (workdir/LinkTarget/CppunitTest/libtest_desktop_lib.so +0x185a42) [...] Change-Id: I935f2e37ce6bcb0448f89e75a4f34f78ba54f58d Reviewed-on: https://gerrit.libreoffice.org/63136 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 015e4266a82ead8135458bd07f01838222521eea)
2021-03-29tdf#123747 xmlsecurity, ODF sign roundtrip: preserve invalid reference typeMiklos Vajna8-18/+83
Only add the correct type to new signatures to avoid breaking the hash of old ones. (cherry picked from commit 8a9d8238bd8f903393ff1184aa37f8973c81e2ba) Conflicts: xmlsecurity/qa/unit/signing/signing.cxx Change-Id: I30f892b292f84a0575a3d4ef5ccf3eddbe0090ca Reviewed-on: https://gerrit.libreoffice.org/70451 Tested-by: Jenkins Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit f82e3b03162bff8ecd0409be21744f2c2b2c9144)
2021-03-29tdf#119309 xmlsecurity xades: missing XML attribute on idSignedProperties refMiklos Vajna2-0/+12
The AdES validator at <https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation> recently learned to deal with ODF files, this improves its output, so that "Qualification Signature" section is no longer just a red "N/A" but an orange "Indeterminate QESig". Change-Id: I5f47b935f1dbfa4e2eee4654db31403479cb571d Reviewed-on: https://gerrit.libreoffice.org/59633 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit ea3a5036d23081b6e8eb38a399ff8ef5acd8adc7)
2021-03-29default to CertificateValidity::INVALIDCaolán McNamara1-2/+2
so if CertGetCertificateChain fails we don't want validity to be css::security::CertificateValidity::VALID which is what the old default of 0 equates to notably commit 1e0bc66d16aee28ce8bd9582ea32178c63841902 Date: Thu Nov 5 16:55:26 2009 +0100 jl137: #103420# better logging turned the nss equivalent of SecurityEnvironment_NssImpl::verifyCertificate from 0 to CertificateValidity::INVALID like this change does Change-Id: I5350dbc22d1b9b378da2976d3b0abd728f1f4c27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110561 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit edeb164c1d8ab64116afee4e2140403a362a1358)
2021-03-29do same set error state as ReadAndVerifySignature doesCaolán McNamara1-0/+1
this function is nearly exactly the same as ReadAndVerifySignature except it doesn't set error-state on exception during parse Change-Id: Ife881f639a11d3185920ca62cc2cd22812fae36d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112366 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112412 (cherry picked from commit 52a23d595b820cab27d76d0e7c129f2757c762d6)
2020-12-03xmlsecurity: reject a few dangerous annotation types during pdf sig verifyMiklos Vajna3-5/+76
(cherry picked from commit f231dacde9df1c4aa5f4e0970535c4f4093364a7) Conflicts: xmlsecurity/source/helper/pdfsignaturehelper.cxx Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105926 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit fcab45e0e22f4cf46e71856dba7ae5abd6f99bc5) Change-Id: I950b49a6e7181639daf27348ddfa0f36586baa65
2020-12-03xmlsecurity: handle MDP permission during PDF verifyMiklos Vajna6-15/+41
(cherry picked from commit 586f6abee92af3cdabdce034b607b9a046ed3946) Conflicts: include/vcl/filter/PDFiumLibrary.hxx vcl/source/pdf/PDFiumLibrary.cxx xmlsecurity/source/helper/pdfsignaturehelper.cxx Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105785 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 00479937dc071246cc27f33fd6397668448a7ed9) Change-Id: I626fca7c03079fb0374c577dcfe024e7db6ed5b3
2020-09-12xmlsecurity: pdf incremental updates that are non-commenting are invalidMiklos Vajna5-3/+95
I.e. it's OK to add incremental updates for annotation/commenting purposes and that doesn't invalite existing signatures. Everything else does. (cherry picked from commit 61834cd574568613f0b0a2ee099a60fa5a8d9804) Conflicts: include/vcl/filter/PDFiumLibrary.hxx vcl/source/pdf/PDFiumLibrary.cxx Change-Id: I4607c242b3c6f6b01517b02407e9e7a095e2e069 Conflicts: xmlsecurity/qa/unit/signing/signing.cxx
2020-09-10xmlsecurity: avoid saying OK when the signature is partialMiklos Vajna2-7/+12
That's reserved for valid signatures (digest match, certificate validates and the signature covers the whole document). Also avoid "invalid" in the dialog when the digest matches and the signature is just incomplete. This now uses wording which is closer to Acrobat and also uses the same wording on the infobar and in the dialog. Change-Id: I26e4781d555b65cf29aa8df2232e286917235dc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101926 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102188 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 46efad443472679b93b282c8e08b807d7e8f1a78) Conflicts: xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx
2020-09-10xmlsecurity: fix infobar vs signature dialog inconsistencyMiklos Vajna1-2/+11
The infobar mentioned if a signature is partial, but the dialog just has a bool UI for signatures. Then present "good, but partial" as "bad". (cherry picked from commit 3ba1144cb96c710e665ffb3ada26fb6a48a03472) Change-Id: I698190aa77702000b11d635bd038d9c9a91614ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101844 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 8696c20cbf5c816ded9fee469616cb693b4572b0) Conflicts: xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx
2020-07-28xmlsecurity: detect unsigned incremental update between signaturesMiklos Vajna6-33/+141
(cherry picked from commit 7468d5df5ec79783eae84b62bdc5ecf12f0ca255) Conflicts: vcl/source/filter/ipdf/pdfdocument.cxx xmlsecurity/source/pdfio/pdfdocument.cxx Change-Id: I269ed858852ee7d1275adf340c8cc1565fc30693 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99480 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-22package: OFFICE-3940 ODF 1.3 import of OpenPGP encryptionMichael Stahl1-0/+0
This was supposed to be implemented by commit a7bf6488ebb544e1efaed0a1e53073df9cc2064d "ODF1.3: import new OpenPGP encryption markup" but it turns out that the ODF 1.3 cs01 schema differs from the implementation: in ODF 1.3 cs01 we have <manifest:encrypted-key> <manifest:encryption-method .../> <manifest:keyinfo> <manifest:PGPData> </manifest:PGPData> </manifest:keyinfo> <manifest:CipherData> </manifest:CipherData> </manifest:encrypted-key> whereas the implementation expects <manifest:keyinfo> <manifest:encrypted-key> <manifest:encryption-method .../> <manifest:PGPData> </manifest:PGPData> <manifest:CipherData> </manifest:CipherData> </manifest:encrypted-key> </manifest:keyinfo> Ideally the inner manifest:keyinfo should be manifest:KeyInfo but not sure if that really matters. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94309 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 4f1b0f7d5235140611305b784b58f95fc5b8bd81) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94586 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit a3ef13b495d5898488ae52981bdaf8cf34db791c) Change-Id: I407321c857e7b3ed9f4d04568ca2ea116764b3da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99155 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-06-26tdf#97694 Add test for macro signature preservation in BaseSamuel Mehrbrodt2-0/+47
Change-Id: I35fb8d499eed66f9a5e208a4778a1f0f12637079 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93630 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 29cb36cbee9c3ff5e73bc7a6d6a2f365c5c62da7)
2020-03-13tdf#42316 always evaluate macro signatures on loadJan-Marek Glogowski1-24/+6
As already stated in the comments of the signing unit tests, disabling macro security will not only ignore the signatures, but actually drop the macro signature, as these are never evaluated and as a result can't be restored for the new document. Change-Id: Ie41a9e72d3367c2eed58a52387bb67d8c41abff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90435 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 929d46bbf42aefc1f6cf046c2b9cf3d7c4e1efc5) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90393 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-01-21Fix macro security UI usability problemsJan-Marek Glogowski3-22/+46
* Don't hide the option dialogs "Macro security" push button. I don't see any reason, why these settings should be hidden, if macros are disabled or settings locked. At least a user can now check, what is going on (still nothing shows disabled macros for a document in the UI AFAIK). * Don't scale the lock icons of the trusted list boxes. This just uses the same alignments, which the macro security level lock image uses, otherwise the image is scaled to fit the whole space of its layout cell. * Don't disable the trusted list boxes. If the setting is locked, it's sufficient to disable all the buttons, which allow modification (so View can stay enabled). This way you can still scroll the list. Correct button handling is already implemented and works for me. * Catch exceptions of broken certificate data. If your config contains certificates, which can't be correctly decoded, the NSS backend will throw an exception, which kills the dialog, but not the nested loop, resulting in a locked LO. Since we don't want a string change in LTS, this drops the whole "broken certificate" warning dialog. There already are SAL_WARNs, which log the same warning, and are considered sufficient for debugging broken configurations. Reviewed-on: https://gerrit.libreoffice.org/85056 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit b3348ce498b3d54b3e5e6518954ad9d5e917b8f2) Reviewed-on: https://gerrit.libreoffice.org/85282 (cherry picked from commit ad1a41032054991cfb8b9e821c1dd25ec21d0aec) Change-Id: I79002e0ce85cf9a9017caf858407f2f635a3a074 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85756 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-11-01tdf#42316 handle saving to template filtersJan-Marek Glogowski1-17/+162
This extends the filter comparison from commit c3a1c83ff5af ("tdf#42316 preserve macro signature of templates"). The original patch just stripped "_template" from the source filter to find equal document types, which just enables the "template => document" case. This patch also strips the "_template" from the target filter, which fixes the "document or template => template" cases. This also extends the signing save tests: * OTT 1.2 => OTT 1.2 - preserve * ODT 1.2 => OTT 1.2 - preserve * OTT 1.0 => OTT 1.0 - preserve * ODT 1.0 => OTT 1.0 - preserve * OTT 1.0 => OTT 1.2 - drop Reviewed-on: https://gerrit.libreoffice.org/80654 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 4aa6e2cb2245eddab87fb451add94159a7604246) Reviewed-on: https://gerrit.libreoffice.org/80910 Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 7b405877b0fa0145513ac0294ab51cf57e6108c6) Change-Id: Ie297258a4d9f9aa4beb25786c6ba240b6f16f49b Reviewed-on: https://gerrit.libreoffice.org/81885 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-10-01tdf#42316 preserve macro signature of templatesJan-Marek Glogowski4-1/+255
When comparing the filter of the current and the target document we have to strip the '_template' from the filter name. Still this won't preserve the signature of the document attached to tdf#42316, as this is a ODF 1.0 OTT, which doesn't have a valid signature in ODF 1.2, as the signature doesn't match the ODF 1.2 namespace for signatures and the default LO ODF version is ODF 1.2 extended. In theory the signature itself could even be converted most times, but that can be done in an additional patch, if needed. Since the code literally saves a template to an internal document, SfxObjectShell::DoSaveCompleted must keep the signature of the template. Eventually it'll be dropped on save of the template as a document later. The signing tests check "OTT 1.0 => ODT 1.0: preserve", "OTT 1.2 => ODT 1.2: preserve" and "OTT 1.0 => ODT 1.2: drop". Reviewed-on: https://gerrit.libreoffice.org/75958 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit c3a1c83ff5af05d34f433ac808adbe85f47e8c18) Reviewed-on: https://gerrit.libreoffice.org/77112 Conflicts: xmlsecurity/qa/unit/signing/signing.cxx Change-Id: I2263093687f5a0568ea781ce3ac9b114c9599add Reviewed-on: https://gerrit.libreoffice.org/79371 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-12-09tdf#118373 xmlsecurity: avoid stderr output on libxmlsec version checkMiklos Vajna1-0/+6
Make sure that our normal SAL_WARN() reporting is registered during the xmlSecCheckVersionExt() invocation, just like it's registered during other libxmlsec API calls. (cherry picked from commit 099ab643f60efc5be6f151bff89651efd2da1fc9) Change-Id: Ia19368b55dbae47974f48954f86b50e36d1462ff Reviewed-on: https://gerrit.libreoffice.org/64626 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-06sfx2: show partial signatures even if cert validation failsMiklos Vajna1-2/+3
(cherry picked from commit 4a59a8aba8c9d451edff790d9281d0095c1bd78e) Conflicts: xmlsecurity/qa/unit/signing/signing.cxx Change-Id: I6060b7130827346ac5d6955bf38ebe3b476819fd Reviewed-on: https://gerrit.libreoffice.org/64174 Tested-by: Jenkins Reviewed-by: Sophie Gautier <gautier.sophie@gmail.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-10-01tdf#116085 make sure Certificate Manager is found with GPG4win v3Cor Nouws1-3/+5
Change-Id: I3a7ab7ec046a6bbff4b4a020e76356ffd454bab8 Reviewed-on: https://gerrit.libreoffice.org/61061 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 89a60912bba7ffd6f65ea99f4664f343c5025c95) Reviewed-on: https://gerrit.libreoffice.org/61173 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-09-20tdf#118567 Signature Line: Fix ooxml signingSamuel Mehrbrodt4-10/+11
Change-Id: Ie2467db7ab209f10e92b6db1f5680e7a9be614ab Reviewed-on: https://gerrit.libreoffice.org/60676 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit c3de0478fbcbe1dc22ab5dea42b423bb8e45fcba) Reviewed-on: https://gerrit.libreoffice.org/60735 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-08-14xmlsecurity: nsscrypto_initialize: try to avoid profile migrationMichael Stahl1-0/+14
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.35_release_notes NSS 3.35 and later will automatically migrate migrate profiles from the old "dbm:" BDB format to the new "sql:" SQLite format. The new format can be read by NSS 3.12 and later, which is old enough that it can be assumed to be available. However LibreOffice still shouldn't migrate the profile on its own: LO typically uses a Mozilla Firefox or Thunderbird profile, and if it is a system Firefox with system NSS libraries, then it's probably a bad idea for LO to migrate the profile under Firefox's nose, particularly considering the "partial migration" scenario if the profile is password-protected. Try to avoid this by checking if the profile is the old format and explicitly using the "dbm:" prefix to prevent the migration. Change-Id: I06480522f830ce74e2fb7bf79fee84ad80979b82 Reviewed-on: https://gerrit.libreoffice.org/58756 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 61688aa1abd9db9adbb8dc5d5aacc6269b21fd27) Reviewed-on: https://gerrit.libreoffice.org/58973 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2018-08-03forcepoint#57 sanity check stream signature sizeCaolán McNamara1-13/+17
Change-Id: I5ae459e159a64f32c62278a87e37deb08ab9d6ac Reviewed-on: https://gerrit.libreoffice.org/58448 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-07-19xmlsecurity UI: restore lost AdES default for PDF signingMiklos Vajna2-3/+9
Regression from 13596e704e4b48e8b0892867b3f3fc351a2729f9 (Don't pass ODF version, just retrieve it directly, 2018-05-17). Change-Id: Ia031e597c610000db2820920c3dc1b58430dcc12 Reviewed-on: https://gerrit.libreoffice.org/57246 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit a9c0289886ee5519d4a718d8e3145d66b187faac) Reviewed-on: https://gerrit.libreoffice.org/57259 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2018-07-06tdf#117901 Write signature line images as emf to ooxmlSamuel Mehrbrodt1-0/+35
Change-Id: Idbf60be3cef2d9dde454da0279d2810488b1e157 Reviewed-on: https://gerrit.libreoffice.org/56871 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 7bafb7ca8ef9467f5c55766d2a38ba0d0a60837c) Reviewed-on: https://gerrit.libreoffice.org/56986 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-06-30ODF1.3: import new OpenPGP encryption markupThorsten Behrens2-0/+8
With OFFICE-3940 the loext markup got accepted for ODF1.3 (and the redundant KeyInfo element removed). Make sure manifest parser can import new markup. Change-Id: Id3c88654e8e6e0e256cd68fbb43f1ef670849cf7 Reviewed-on: https://gerrit.libreoffice.org/56597 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit a7bf6488ebb544e1efaed0a1e53073df9cc2064d) Reviewed-on: https://gerrit.libreoffice.org/56677
2018-06-29tdf#118425 xmlsecurity UI: fix OOXML signingMiklos Vajna1-0/+5
Regression from 13596e704e4b48e8b0892867b3f3fc351a2729f9 (Don't pass ODF version, just retrieve it directly, 2018-05-17), just checking the file format explicitly like the PDF signing does fixes the problem. Change-Id: I1ba7cf9096e01c6c5a2d3875b08fa3a66acae829 Reviewed-on: https://gerrit.libreoffice.org/56635 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 02119ce226ef7c1fcf419aa0933aa95381ee309b) Reviewed-on: https://gerrit.libreoffice.org/56663 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2018-06-14Move signature line to signed propertiesSamuel Mehrbrodt2-61/+53
So that a modification will result in an invalid signature. Change-Id: Ib40e0b941d56e29c134993e1d41f496aa183bd7f Reviewed-on: https://gerrit.libreoffice.org/55086 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2018-06-08Fix CppunitTest_xmlsecurity_signing with system-xmlsec 1.2.26Miklos Vajna1-14/+37
Swap the order of the default and custom callback registration, since the order of lookup is now reversed since <https://github.com/lsh123/xmlsec/commit/968646fb9b8428174a112fce2f08b1ec89d0ed97>. Thanks Tomas Chvatal for reporting this. (cherry picked from commit 576f899811a22e83b6fb6a120c8da303b1f4cac1) xmlsecurity: check for the libxmlsec version runtime, not build-time For the general benefit of --with-system-xmlsec usage scenarios (where LO may be built against an old version of xmlsec and run against a new one). (cherry picked from commit bc4e43dd926bbe6f5315b5c372770ac8c7222177) Change-Id: I60a347454701a679db4ccd8924a723a236d5edff Reviewed-on: https://gerrit.libreoffice.org/55462 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-24xmlsecurity: Ask current datetime only onceTakeshi Abe3-11/+6
... and pass it as the sole argument to XMLSignatureHelper::SetDateTime(). Change-Id: I7f3e8dc90bb34ca347a1ad5a79717a338af3bed9 Reviewed-on: https://gerrit.libreoffice.org/54706 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-05-23Remove leftover "#undef DEBUG"Stephan Bergmann2-15/+0
...which might have had a purpose in the past, but look unused today. (DEBUG is defined in solenv/gbuild/gbuild.mk iff dbglevel >= 2, and `make Library_xsec_xmlsec dbglevel=2` doesn't run into any problems for me with the undefs removed.) Change-Id: I7f941e8c2d454f4206fb17bc791247606ffe6309 Reviewed-on: https://gerrit.libreoffice.org/54718 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-05-22Related tdf#83877 Select certificate ok button label doesn't matchSamuel Mehrbrodt4-2/+24
Change the button to "Select" instead of sign when we only want to select a certificate. Change-Id: Ifa896e502c8680497d71912ddd1058ab0b71542b Reviewed-on: https://gerrit.libreoffice.org/52823 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 08:45:09 +0000