Given recent elections we need to build a higher wall to keep the
government out of our documents, and we will make the government
pay for it.
These iteration counts were considered appropriate a decade ago.
http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256
We get similar numbers on SandyBridge-E desktop and Haswell i7-4600U laptop:
* with 10k iterations ~20 msec per derivation
* with 100k iterations ~195 msec per derivation
* with 150k iterations ~290 msec per derivation
We can't go too high though because in ODF every package stream gets
its own derived key with a different salt, so a document with embedded
images may need a lot of these.
Change-Id: I6894e71ed399f8c340eff97a9191c8d8419789a6
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
ODF 1.2 uses an incorrect URL to refer to SHA256, add support for the
correct W3C URL on import but continue to export the incorrect URL for
now.
Change-Id: I3135bcf989070d20f85f14702db07595f304e706
If more than one place in the code submits tasks to the shared
pool, then waitTillDone() becomes unreliable.
Add a tagging mechanism, so different callsites can wait
on different sets of tasks.
Also try to protect our worker threads against exceptions from
the thread tasks code.
Change-Id: Idde664ab50008d31a2dd73910bb22f50e62ae22f
Reviewed-on: https://gerrit.libreoffice.org/27042
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
For no good or obvious reason, SfxMedium::StorageCommit_Impl() swallows
embed::UseBackupException if there is a pTempFile, which (as the comment
claims) is "always now". This results in the temp file actually being
copied to the user-visible file and the SaveAs "succeeding", when it
clearly did not.
Also move the exception throwing to the end of ZipOutputStream::finish()
to avoid more memory leaks.
Change-Id: I448cc43291754ef20adfa6b65916282fcc365a11
In the bugdoc of tdf#91807 there are at least 49 corrupt zip streams
that raise exceptions in the DeflateThreads. Because the maximum
allowed number of threads happens to be 48, this results in an infinite
loop in ZipOutputStream::reduceScheduledThreadsToGivenNumberOrLess().
(regression from 7e2ea27e5d56f5cf767a6718a0f5edc28e24af14)
In case an exception is thrown, don't re-throw it immediately, which
might cause trouble such as leaking all of the ZipOutputEntry instances
in m_aEntries.
Change-Id: Ia74ab8e46fa1349c049d05dbec3454bfbe7d61d9
A new static member getPreferredConcurrency added to
comphelper::ThreadPool to return a configurable max
number of threads.
By default the new function returns the hardware_concurrency
value provided by std::thread. When MAX_CONCURRENCY envar is
defined, the return value is limited to whatever is set there.
Three call-sites that used std:🧵:hardware_concurrency
have been replaced with getPreferredConcurrency.
Unittests added to cover the functionality of the new member.
Unittests are capped to 4 threads.
Change-Id: I3332e393a88a5ed436316fa712ed920a4b37f4af
Reviewed-on: https://gerrit.libreoffice.org/26254
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Searched source for using declarations.
Checked if those symbols reappear in the source file,
even in comments or dead code but not in #include statements.
If they don't reappear, remove the declaration.
Remove includes whose symbol got removed.
Change-Id: Ibb77163f63c1120070e9518e3dc0a78c6c59fab0
Reviewed-on: https://gerrit.libreoffice.org/24148
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
At ODT export time writing and zipping comtained data packages is nicely
parallelized, but not limited to an upper bounds of threads to use.
Together with memory consumption this makes ressource usage and runtime
behaviour bad to crashing (mostly on 32bit).
I have now limited the processing dependent on the number of available
cores to get a good processing/ressource ratio. The result uses much less
memory, is faster and runs on 32bit systems.
Change-Id: I8bd516a9a0cefd644f5d7001214bc717f29770ab
Reviewed-on: https://gerrit.libreoffice.org/23305
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
(as some tests derive from the latter only for the Directories part, not for the
setUp/tearDown overrides: those tests will be cleaned up next)
Change-Id: Ib6b78eea868b8bc21d4cc6e8fd9e1d025deca05f
Reviewed-on: https://gerrit.libreoffice.org/23078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
create an InterfaceContainer2 class to replace InterfaceContainer.
It uses a std::vector instead of a Sequence for the mutable listener
list, which provides far better performance.
Switch all our internal use-sites to the new class.
Change-Id: I6b56cfa511ded2395faa22e68fab3b2f16c3cb88
Somewhat arbitrarily prefer public over private derivation; the former is what
is used by default across the code base.
Change-Id: I936c1b0d3231ac97015863f396a5af49f6c9647b
I see "warn:legacy.osl:22439:1:package/source/zipapi/ZipFile.cxx:583:
Can't detect password correctness without digest!"
when opening file saved with password.
Obviously css::xml::crypto::XDigestContext used in ZipOutputEntry does not
work properly when encrypting files in parallel, so don't do that.
Change-Id: I4b354535240a4f31a6bc6855cf7f9af527634e7e
Reviewed-on: https://gerrit.libreoffice.org/21238
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Matúš Kukan <matus@libreoffice.org>
