The only implementation of css::xml::crypto::XXMLSignatureTemplate is
XMLSignatureTemplateImpl, so work with that directly instead of going
via UNO.
Change-Id: I85e2169a909b689620c2ce125a9653f9a6696f45
Reviewed-on: https://gerrit.libreoffice.org/40950
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
and the vast majority of translations is to the ui language so default
ctor with that arg
and now drop OModuleResourceClient
Change-Id: I3b85a560ffdfe5f019c2271ac56a5fe4a361522b
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun:⭐:resource::OfficeResourceLoader
com::sun:⭐:resource::XResourceBundleLoader
com::sun:⭐:resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
First steps to organize an importer that can read/interpret
wmf/emf/emf+ and deliver a primitive representation for
the content by parsing it. Use the same mechanisms as
already applied for Svg, so to reuse abilities to keep
original binary data to allow save again and embedding in
files and have an implemented replacement bitmap based
representation. For this, unify the used helper classes
to handle more than just Svg. For 1st try, add test code
and static bool switches
Change-Id: I6e0a82943541d811a8f8d65a84115569fcd8cee7
The only remaining difference is that in the system-xmlsec case we work
with the default key manager, not with the one that's only added by our
xmlsec patches.
This works for me for the uses I know of (see
<https://lists.freedesktop.org/archives/libreoffice/2017-February/076947.html>
for the motivation): signing and verifying of different signatures (bad
signature, good with non-trusted CA, good with trusted CA) with
software-based certificates all behave as expected.
Change-Id: If3f3e2b8373ab7397db3f98070a5a2ce51fa7c06
Reviewed-on: https://gerrit.libreoffice.org/39075
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Sadly we only know whether its a OpenPGP or X509 signature during
parsing, so we need to switch the implementation mid-way
Change-Id: Ib48a9da0105de62cfecda095df8c154b59ba8c40
In the end, the gpgme implementation uses enough of xmlsec
functionality that splitting those (and ending up with two copies)
was just not worth it.
Change-Id: Ida87c848e4e6a770e3c697add9ceb589a9ec3930
xmlsec1-customkeymanage.patch.1 of our bundled xmlsec extends
xmlSecNssKeyDataX509VerifyAndExtractKey(), so that it calls
xmlSecNssPKIAdoptKey() for the private key of the signing certificate.
Make this explicit in xmlsecurity/ code, so we don't depend on the
patched xmlSecNssKeyDataX509VerifyAndExtractKey().
This is harmless for the patched xmlsec, but it prevents this error:
warn:xmlsecurity.xmlsec:26221:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: keys.c:1246: xmlSecKeysMngrGetKey() '' 'xmlSecKeysMngrFindKey' 1 ' '
warn:xmlsecurity.xmlsec:26221:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:790: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:26221:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:503: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' '
warn:xmlsecurity.xmlsec:26221:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:286: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxSignatureProcessNode' 1 ' '
when xmlsec is not patched.
(This is needed, but not enough to build against system xmlsec.)
Change-Id: I5d68a8be7aefcb529566213f9b9c2985eab6a80a
Reviewed-on: https://gerrit.libreoffice.org/39023
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
change various ResId classes that use conversion operator to OUString to
functions that return a OUString
drop various defines
drop unnecessary toString calls
Change-Id: Ibeccdf2b91a46a2ed5b4b74e6024e301a023bc92
Reviewed-on: https://gerrit.libreoffice.org/37817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
