gpgme contexts uses the "auto" trust model by default which only
allows encrypting with keys that have their trust level set to
"Ultimate". The gpg command, however, gives the user the option
to encrypt with a certificate that has a lower trust level so
emulate that bahavior by asking the user if they want to trust
the certificate for just this operation only.
Also, abort saving if no certificates are selected which is an
indication that the user cancelled the Select Certificate dialog.
Change-Id: I20951b1e31b2dcf8adb82243742f8c00fbaca8c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165260
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The cui module has its own UserData struct and when building with
--enable-mergelibs=more, this data collision will cause a crash
when deleting a UserData instance in the xmlsecurity module because
the cui module already has its own, unrelated UserData struct.
Change-Id: I6418b049c72a2e902c9b5076b72fd240f65a593d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164404
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
using the bin/find-can-be-private-symbols.py script
to find classes with large numbers of exported symbols
that can hidden.
before
exported = 58104
imported = 30810
unused_exports = 35433
after
exported = 55094
imported = 31073
unused_exports = 32423
Change-Id: Idd0a70ee3740afd5ca1a86771e0e2ff8090d102d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reusing the same instance will, in the following case, lead to a
crash. It appears that the CertificateChooser is getting disposed
somewhere as mpDialogImpl in its base class ends up being null:
1. Create an empty Writer document and add a digital signature
in the Digital Signatures dialog
2. File > Save As the document, check the "Encrypt with GPG key"
checkbox, press Encrypt, and crash in Dialog::ImplStartExecute()
Change-Id: I9aaa1bd449622e018b502d68c53d397255a1b61a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163065
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
looks like the new row gets sorted immediately when added as an empty
row into the first row, so accessing it by index later to set it text/id
get an unexpected result.
pause sorting while inserting the entries and enable it again when
finished for the easiest fix.
Change-Id: Ib028b193afbf2b9026841b19419e012b70448e39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162993
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Most, if not all, of the Linux certificate manager applications are
not available on macOS so create a separate list for macOS.
Also, fix uncloseable windows due to uncaught exceptions thrown by
XSystemShellExecute::execute(). Failure to catch such exceptions
would cause the document window to be uncloseable and the application
to be unquittable.
Change-Id: I9bc6dc9c6c9d054252b634874045cb066023214a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162887
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The new tests fail with:
> core/xmlsecurity/qa/unit/signing/signing2.cxx:
> 252: Assertion
> Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody
> equality assertion failed
> - Expected: 1
> - Actual : 4
This is because only the first test that runs sees the testing CA
certificates that are copied in MacrosTest::setUpNssGpg(); when the
second test runs, they have somehow vanished.
This is because apparently SQLite on MacOSX, unlike on Linux, monitors
the file descriptors of its database files, and then invalidates itself
when setUpNssGpg() via osl::File::copy() renames and unlinks the
existing database files:
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x11)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x11)
Split MacrosTest::setUpNssGpg()/tearDownNssGpg() into functions
setUpX509() which only does something on the 1st invocation, and
setUpGpg()/tearDownGpg() which may be invoked per-test (they could also
be run once for the whole test suite, but not obvious how to do that);
PDF related tests don't need GPG.
Presumably this is (along with the WNT-specific problem fixed in commit
3e9a700091) the reason why most of the
tests not only accept the expected result of SignatureState::OK but also
SignatureState::NOTVALIDATED.
Change-Id: I59b85ca651cecaccfdea729ed1e645c53079c8bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162693
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...which had always cut off an existing path ever since
92b6ffcd9f "Allow selecting a custom certificate
manager", for reasons that are unclear to me.
So if an existing setting contains at least one slash (or backslash, on
Windows), try to use it as-is; otherwise, keep searching for it in aPath. (And,
in any case, make sure to report back the given value in sExecutable.)
Change-Id: I8b2b6ac7a449d7afd02e029ff46d4c79e6b824e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162703
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Commit 4d6e9d5e15 added 2 tests that
always fail on WNT, unfortunately Jenkins doesn't actually run the
tests.
There are 3 certificates involved:
"Xmlsecurity RSA Test Root CA"
"Xmlsecurity Intermediate Root CA"
"Xmlsecurity RSA Test example Alice"
In the signature XML, there are 3 elements that contain or reference
certificates:
1. X509Data - xmlsecurity produces only the signing certificate here
2. xd:SigningCertificate (XAdES) - again only the signing certificate
3. xd:EncapsulatedX509Certificate (XAdES) - xmlsecurity produces the
full certificate chain here
All of these elements *could* contain the full certificate chain, but in
LO-produced XML signatures only 3. does.
The problem is that the function CheckUnitTestStore() that looks up
a certificate in a unit-test-specific CA store via
$LIBO_TEST_CRYPTOAPI_PKCS7 can only handle a root certificate, it does
not recursively retrieve and check a certificate chain.
The SecurityEnvironment_MSCryptImpl::verifyCertificate() already has a
parameter "seqCerts" to pass in the full certificate chain, but due to
the way the data from the XML is processed, it gets passed only the
content of the X509Data element(s), which, for LO-produced signatures,
do not contain the full certificate chain.
Instead of improving the unit-test-specific function, let's try to get
all the certificates out of the XML signature, and then pass them to
verifyCertificate().
Of course this requires some consistency checks so that the verification
can't be fooled by different certificates in different XML elements.
Change-Id: I8ca541887ceac2dfb6af5d96a5565cfa58d7f682
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162170
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Extend external/xmlsec/old-nss.patch.1, our bundled NSS in debug builds
has some assert failure in relatively new xmlsec code, just disable it
for now till it's clarified with upstream how to sort that out properly.
E.g. CppunitTest_filter_svg fails like this:
#1 0x00007ffff77503e5 in abort () at /lib64/libc.so.6
#2 0x00007ffff679ca90 in PR_Assert (s=0x7ffff44fbfe5 "oidmechhash != NULL", file=0x7ffff44fbfb6 "secoid.c", ln=2140) at ../../../../pr/src/io/prlog.c:571
#3 0x00007ffff44eaae0 in SECOID_FindOIDByMechanism (mechanism=307) at secoid.c:2140
#4 0x00007ffff6660c65 in PK11_MechanismToAlgtag (type=307) at pk11mech.c:1745
#5 0x00007fffe874e4ea in xmlSecNssCryptoCheckMechanism (type=307) at crypto.c:68
#6 0x00007fffe874ec44 in xmlSecNssUpdateAvailableCryptoTransforms (functions=0x7fffe87ffbc0 <functions>) at crypto.c:401
#7 0x00007fffe874f13d in xmlSecNssInit () at crypto.c:552
#8 0x00007fffe86b2c36 in initXmlSec() () at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/xmlsec/xmlsec_init.cxx:42
#9 0x00007fffdf3c54f2 in DocumentSignatureManager::init() (this=0x7fffffff3970) at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/helper/documentsignaturemanager.cxx:79
#10 0x00007fffdf43e3da in (anonymous namespace)::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)
(this=0x1c07ac0, rxStorage=uno::Reference to (OStorage *) 0x1944e18, xSignStream=empty uno::Reference, eMode=DocumentSignatureMode::Macros)
at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/component/documentdigitalsignatures.cxx:486
#11 0x00007fffdf43da17 in (anonymous namespace)::DocumentDigitalSignatures::verifyScriptingContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) (this=0x1c07ac0, rxStorage=uno::Reference to (OStorage *) 0x1944e18, xSignInStream=empty uno::Reference)
at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/component/documentdigitalsignatures.cxx:373
#12 0x00007fffe6fa06df in SfxObjectShell::GetDocumentSignatureInformation(bool, com::sun::star::uno::Reference<com::sun::star::security::XDocumentDigitalSignatures> const&)
(this=0x188c280, bScriptingContent=true, xSigner=empty uno::Reference) at /home/vmiklos/git/libreoffice/core/sfx2/source/doc/objserv.cxx:1847
Change-Id: I36dee0d2b128a6931875572aa4acc9df940ab623
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161951
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
what I'm really after is some vexating not-reproducible oss-fuzz msan
warnings when using libxml2 in the fodt2pdf fuzzer. So lets upgrade
libxml2 to the latest, which requires bumping libxslt, and then requires
a newer liblangtag because of no longer implicit includes that it
depended on.
xmlKeepBlanksDefaultValue and xmlSubstituteEntitiesDefault are
deprecated, we should get around to updating those uses
Change-Id: I8fda0dffda0a7ea65407d246a3121875cb8ad4a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161598
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
The old name was misleading (it doesn't take an URL, but a filename);
also, now it's easier to grep for it - doesn't get mixed with
vcl::graphic::loadFromURL.
Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
With PCH, the earlier workaround with NSS_PKCS11_2_0_COMPAT breaks -
so lets fix this with conditionals, its only two places.
Follow-up commit to 9276d5338e
Change-Id: I7d3292304d83d784ee9dce5cdc62b4a028ff333a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161204
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
This is essentially a footgun because the user can accidentally turn it
off and get non-AdES signatures which use obsolete SHA1 hashes.
Unfortunately it turns out that the initial setting of the checkbox only
works for ODF, because OOXML have m_sODFVersion set to "1.0" due to some
defaulting code somewhere.
So what this checkbox actually did is unintentionally disable XAdES
signatures for OOXML by default.
Now that i actually test it by setting ODF version 1.1 in
Tools->Options, it turns out that signing ODF 1.1 documents isn't
possible at all, a dialog pops up that says "Signing documents
requires ODF 1.2 (OpenOffice.org 3.x)".
Change-Id: I0eaf590c290b2c0ee0ff890ed73f0dbea4cf0ce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160785
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... 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>
(*) Make all of it use a "Scoped" paradigm
(*) pass by value, no need to allocate on heap
(*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods.
(*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places.
Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Seen in a fedora:40 container, using --with-system-libcmis,
--with-system-liblangtag and --with-system-xmlsec.
Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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>
Andrea Gelmini