+ improve SALT management by taking the max between encryptedHashInput.size()
and comphelper::roundUp(mInfo.saltSize, mInfo.blockSize)
+ add QA tests
Change-Id: I90dce73928e0b204500ac659eb80cd1499a4f065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184407
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Also move the relevant tests and clean-up the names a bit to make
it mroe consistent.
Change-Id: I929ef9c13b954fd6a506471231d1bc41e4ef9980
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176027
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
V1037 Two or more case-branches perform the same actions. Check lines: 289, 293
Change-Id: I9828b4d5b7faca449c5377a0bd8223cddf883a43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175423
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Seeing as since:
commit e9531b792d
Date: Tue Feb 6 14:39:47 2024 +0100
sal: rtlRandomPool: require OS random device, abort if not present
Both rtl_random_createPool() and rtl_random_getBytes() first try to get
random data from the OS, via /dev/urandom or rand_s() (documented to
call RtlGenRandom(), see [1]).
we don't use the initial arg to rtl_random_getBytes anymore, drop the
requirement to have one. Then simplify our usages of that, and
addtionally deprecate rtl_random_createPool and rtl_random_destroyPool.
Change-Id: I13dcc067714a8a741a4e8f2bfcf2006373f832c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167067
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
There is no need for it to be an UNO interface anymore (ever since
we started supporting dynamic_cast on UNO objects).
Which means that XImportFilter2 also needs become a C++ interface.
Change-Id: Ice2db0f098271bba32b199bd083b08cb8410ce93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152388
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
...without which CppunitTest_sw_ooxmlencryption failed on (big-endian) s390x:
* The 32-bit segment counter in AgileEngine::de-/encrypt apparently needs to be
stored in LSB format (at least, if it is, CppunitTest_sw_ooxmlencryption
ultimately succeeded, whereas otherwise it failed).
* The UTF-16 string in Standard2007Engine::calculateEncryptionKey apparently
needs to be in LSB format (at least, if it is, CppunitTest_sw_ooxmlencryption
ultimately succeeded, whereas otherwise it failed).
* The various 32-bit values in the EncryptionStandardHeader and
EncryptionVerifierAES data structures apparently need to be written out in LSB
format in Standard2007Engine::writeEncryptionInfo, given that they are always
read in LSB format in Standard2007Engine::readEncryptionInfo.
Change-Id: I3a1efbfe324b1bbd539b88dc5d40bb44f9676ffa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103315
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
do more like
commit 121771e37f
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
To permit pluggable crypto services, abstract existing
implementation behind an XPackageEncryption API.
Previous code already had two halfway-polymorphic classes (agile and
standard 2007 engine), so we're not adding much additional layers.
As MS crypto always uses OLE storage to wrap content into one single
file, current implementation passes all substorage names down into
XPackageEncryption APi, so different downstream implementations (e.g.
for MS RMS, or Azure AIP) are possible.
Because OleStorage classes are internal to LibO core, access is provided
via XInput/XOutput stream API function.
Change-Id: Icc32a4e0ce215090c3b739f1dcaa0654b36b7f08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84436
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Xisco Fauli