Eike Rathke [Thu, 16 Feb 2023 19:20:31 +0000 (20:20 +0100)]
[PATCH] Obtain actual 0-parameter count for OR(), AND() and 1-parameter functions
OR and AND for legacy infix notation are classified as binary
operators but in fact are functions with parameter count. In case
no argument is supplied, GetByte() returns 0 and for that case the
implicit binary operator 2 parameters were wrongly assumed.
Similar for functions expecting 1 parameter, without argument 1
was assumed. For "real" unary and binary operators the compiler
already checks parameters. Omit OR and AND and 1-parameter
functions from this implicit assumption and return the actual 0
count.
Caolán McNamara [Wed, 23 Mar 2022 13:03:30 +0000 (13:03 +0000)]
add infobar to prompt to refresh to replace old format
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131976 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit bbd196ff82bda9f66b4ba32a412f10cefe6da60e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132307 Reviewed-by: Sophie Gautier <sophi@libreoffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
(cherry picked from commit c5d01b11db3c83cb4a89d3b388d78e20dd3990b5)
Change-Id: Id99cbf2b50a4ebf289dae6fc67e22e20afcda35b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133906 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Gbp-Pq: Name 0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch
Caolán McNamara [Mon, 21 Mar 2022 20:58:34 +0000 (20:58 +0000)]
[PATCH 2/4] CVE-2022-26307 make hash encoding match decoding
Seeing as old versions of the hash may be in the users config, add a
StorageVersion field to the office config Passwords section which
defaults to 0 to indicate the old hash is in use.
Try the old varient when StorageVersion is 0. When a new encoded master
password it set write StorageVersion of 1 to indicate a new hash is in
use and use the new style when StorageVersion is 1.
Change-Id: I3174c37a5891bfc849984e0ec5c2c392b9c6e7b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132080 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit e890f54dbac57f3ab5acf4fbd31222095d3e8ab6)
Gbp-Pq: Name 0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
Michael Stahl [Thu, 25 Feb 2021 13:17:48 +0000 (14:17 +0100)]
xmlsecurity: improve handling of multiple X509Data elements
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)
Caolán McNamara [Mon, 8 Feb 2021 17:05:28 +0000 (17:05 +0000)]
default to CertificateValidity::INVALID
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
Michael Stahl [Thu, 18 Feb 2021 18:22:31 +0000 (19:22 +0100)]
xmlsecurity: XSecParser confused about multiple timestamps
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)
Stephan Bergmann [Wed, 23 Sep 2020 09:41:05 +0000 (11:41 +0200)]
Convert attribute value to UTF-8 when passing it to libxml2
Using toUtf8, requiring the OUString to actually contain well-formed data, but
which is likely OK for this test-code--only function, and is also what similar
dumpAsXml functions e.g. in editeng/source/items/textitem.cxx already use.
This appears to have been broken ever since the code's introduction in 553f10c71a2cc92f5f5890e24948f5277e3d2758 "add dumpAsXml() to more pool items",
and it would typically only have written the leading zero or one
(depending on the architecture's endianness) characters. (I ran across it on
big-endian s390x, where CppunitTest_sd_tiledrendering
SdTiledRenderingTest::testTdf104405 failed because of
> Entity: line 2: parser error : Input is not proper UTF-8, indicate encoding !
> Bytes: 0xCF 0x22 0x2F 0x3E
> ation=""/><SfxPoolItem whichId="4017" typeName="13SvxBulletItem" presentation="%
> ^
apparently reported from within libxml2.)
Change-Id: I4b116d3be84098bd8b8a13b6937da70a1ee02c7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103236 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
Gbp-Pq: Name bigendian.diff
Vincas Dargis [Sat, 4 Aug 2018 14:40:05 +0000 (17:40 +0300)]
[PATCH] apparmor: use dri-enumerate abstraction
Remove backported rule and use new dri-enumerate abstraction instead.
dri-enumerate is available in AppArmor 2.13, which recently migrated
into Debian Buster.
Gemeinsame Unterverzeichnisse: odk-old/config und odk/config.
Gemeinsame Unterverzeichnisse: odk-old/docs und odk/docs.
Gemeinsame Unterverzeichnisse: odk-old/examples und odk/examples.
Gemeinsame Unterverzeichnisse: odk-old/config und odk/config.
Gemeinsame Unterverzeichnisse: odk-old/docs und odk/docs.
Gemeinsame Unterverzeichnisse: odk-old/examples und odk/examples.
14:13 < mst__> _rene_, the toolkit unoapi tests are known to be flaky (in some
system dependent way) e.g. on the Win@6 tinderbox it always
crashes
14:14 < mst__> _rene_, sc.ScAccessible* tests also fail on some systems some of
the time
* LTS team upload
* Fix CVE-2024-12425:
Path traversal leading to arbitrary .ttf file write
Various file formats can contain embedded font files which
are extracted to temporary files which are added to
LibreOffice's font lists.
Prior to this fix, an attacker could craft a document
with embedded font file path names which could cause
LibreOffice to write the contents of the embedded font
to a filename in an arbitrary location the user has
permission to write to. Albeit always with a
".ttf" suffix.
* Fix CVE-2024-12426
URL fetching can be used to exfiltrate arbitrary INI
file values and environment variables
URLs could be constructed which expanded environmental
variables or INI file values, so potentially sensitive
information could be exfiltrated to a remote server on
opening a document containing such links.
Prior to this fix, documents could include links that
made use of an internal feature that expands environmental
variables and INI file values in URLS. In the fixed version,
the expansion feature is not available in document hosted urls.
* Remove CJK test that fail on some builder (flaky test)