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>
in a handful cases, like a map or a vector, we don't need init on demand
at all, the default constructor can be laid out at compile time
Change-Id: I2d404584b5aa23db7b1f779e160e04e72dd2aa74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119656
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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.
Change-Id: I5254aa393f8e7172da59709923e4bbcd625ec713
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111254
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Recheck after 7-0 branchoff
Also drop the now unused file include/vcl/field.hxx
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
So it can avoid SfxObjectShell::Current(), which is only correct when a
single document is open.
Also add an sfx2::DigitalSignatures interface so this can be done
without UNO API changes.
Change-Id: Ie81996b8f1e8851975b27c43a53f9d23e316004e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97116
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
... to configuration and UI.
The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and
stored as value "3" in configuration.
Adapt a few places related to DocumentDigitalSignatures etc. to new
default.
Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Add support for macro and package signing with a provided certificate
which is already possible for document signing since LO 6.2:
boolean signScriptingContentWithCertificate(
[in] ::com::sun::star::security::XCertificate xCertificate,
[in] ::com::sun::star::embed::XStorage xStorage,
[in] ::com::sun::star::io::XStream xStream);
boolean signPackageWithCertificate(
[in] ::com::sun::star::security::XCertificate xCertificate,
[in] ::com::sun::star::embed::XStorage xStorage,
[in] ::com::sun::star::io::XStream xStream);
Change-Id: I9783cd317a7202691913be186eca95964b1e0ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86141
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I89c77656ea4021cb16bd122cb1dd1cd803390c3d
Reviewed-on: https://gerrit.libreoffice.org/71765
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
All hxx cleaned except the ones in
xmlsecurity/source/xmlsec/mscrypt
Change-Id: I651f53c9d339208b3132f9078a5c3829ff9c5dc8
Reviewed-on: https://gerrit.libreoffice.org/71448
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
look for mixed indentation in compound statements, which makes them hard
to read, and sometimes makes it look like a statement is associated with
a nearby if/for
Change-Id: Ic8429cee1f9a86d938097a4a8769a2bce97b3361
Reviewed-on: https://gerrit.libreoffice.org/63283
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I937ed12f2a96943664087ddcdd035f1347e84a57
Reviewed-on: https://gerrit.libreoffice.org/67102
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I98f49765c6b74808dcbd692e0f375dd2848fcfd4
Reviewed-on: https://gerrit.libreoffice.org/65614
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Move the xmlsec helper methods to comphelper so that we can use them in cui
Change-Id: If9b10cfff5f5abd6b16e48f043af7959edbb1142
Reviewed-on: https://gerrit.libreoffice.org/63198
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
...and has always represented the time of day in 100th of seconds. When
tools::Time had been changed to 64 bit nanoseconds in
9830fd36db "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>
Also fixes a bug where signing was aborted after saving as docx.
Change-Id: Ic42b7de2400be0bc55da03b017a545ceaedef9f9
Reviewed-on: https://gerrit.libreoffice.org/60480
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories w* x*
Change-Id: I27bff44da3d34d24262031c7489e755311599bc5
Reviewed-on: https://gerrit.libreoffice.org/57307
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Caolán McNamara