Description: After updating from 5.2.5.1 to 5.3.0.3, saving became much, much slower. So slow that I had to downgrade to 5.2.5.1 again, which solved the problem. In 5.2.5.1, saving is almost instantaneous, i.e. a few hundred milliseconds (the document is small, 20 KB, 7 pages, 1716 characters). In 5.3.0.3, saving takes several seconds, around 5 to 7 seconds before you can actually type again. And as I save frequently while typing (often after each sentence), this stops me in my writing. My computer is a relatively fast i5, with 8 GB RAM and a fast SSD, so the computer or drive is not the culprit. This is also indicated by the fact that downgrading to 5.2.5.1 solved the problem. The document is password protected, if that matters. The problem is so annoying that I had to downgrade to 5.2.5 and will have to stay at that version until the bug has been solved. Steps to Reproduce: 1. Open the document. 2. Save it (press Ctrl+S). Actual Results: It takes several seconds before I can type again. Around 5-7 seconds. Expected Results: Saving should be almost instantaneous, 2-300 ms. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Hello, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170830
Created attachment 135887 [details] Empty document exhibiting the behaviour, password is p It took a while to add more information, as I had to spend some time installing a new version of LibreOffice again, and also had to figure out how to clean the original document. But instead of trying to clean the original, I am simply attaching an empty, new document saved with a password ("p") from LibreOffice 5.4.1.2. Opening that still takes 5 to 7 seconds after entering the password before I am free to type with no lag. Saving it also takes way too long time; it takes several seconds (at least 2 or 3) from the save is initiated until what I type is reflected immediately on the screen. That's too long and ruins the user experience. It's so slow that I cannot upgrade from LibreOffice 5.2 but have to stay on the 5.2 branch until this bug has been fixed. Opening and saving password protected documents like the supplied one was super fast in version 5.2.6.2. I'll probably try to go back to 5.2.7.2 and see if that will do. In LibreOffice 5.4.1.2, saving and opening documents *without* password is super fast with no problems. If you have problems reproducing the bug, maybe the computer you are using is too fast. In that case try with a slower, more normal computer. Not that I believe my computer is slow in any way, but it's not a gaming computer, just an ordinary i5 laptop.
Created attachment 136012 [details] Example file 1. Open the attached file (notice the fast opening speed) 2. File -> Save as -> Enter password 'p' -> Notice saving is slow 3. Open the saved file -> slower as initial file Repro with: Version: 6.0.0.0.alpha0+ Build ID: ec67943f59e09f0f933182f52e582e28b3f258bc CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-08-31_07:23:27 Locale: nl-NL (nl_NL); Calc: CL and with: Version: 5.3.0.0.beta2+ Build ID: f4b7650ecd46e5404b35dccfb8b7d3b0a385d633 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2016-12-16_12:19:09 Locale: nl-NL (nl_NL); Calc: CL but not with: Version: 5.2.5.0.0+ Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55 Locale: nl-NL (nl_NL); Calc: CL
*** Bug 112881 has been marked as a duplicate of this bug. ***
A follow-up (I am the original reporter, not a LibreOffice developer): I am now using version 5.2.7.2 (currently the latest in the 5.2 series), and the problem is not there; saving password encrypted files is super fast. I will have to stay with this version until the problem has been solved. For others with the same problem, version 5.2.7.2 can be found at https://downloadarchive.documentfoundation.org/libreoffice/old/5.2.7.2/ . All old versions can be found at https://downloadarchive.documentfoundation.org/libreoffice/old/ .
Wow, congratulations - you finally found a duplicate to my report. I would appreciate to get this annoying behaviour fixed after 8(!) months! I cannot imagine zillions of commits affecting encryption while saving between 5.2 and 5.3 builds. By the way, 8 months might be the time since I noticed the bug and it was so critical that I was expecting it to be fixed shortly after that...
Setting to All. Linux builds are also affected
Created attachment 137784 [details] Bibisect log Regression introduced by: author Michael Stahl <mstahl@redhat.com> 2016-11-09 17:42:46 (GMT) committer Michael Stahl <mstahl@redhat.com> 2016-11-09 18:07:20 (GMT) commit 25205d5b29d0aade0ebd7c6405a91995d02a3a7c (patch) tree b59667a739670467f2a8a4ad524cac8640fdb100 parent 2a5bb08a2c84470a7a33547ee478d3c26f7ae159 (diff) package: ODF: bump PBKDF2 iteration counts 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.
Adding CC to: Michael Stahl
If the regression is caused by a sudden extreme increase in the number of iterations, then first of all I feel pissed off by the arrogance of just changing that out of the blue (if it was actually known by Michael that it would make saving noticably slower), and second of all I find it interesting how Michael referred to https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256, when the most popular and accepted answer (https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256#answer-3993) starts by clearly stating: "You should use the maximum number of rounds which is tolerable, performance-wise, in your application. The number of rounds is a slowdown factor, which you use on the basis that under normal usage conditions, such a slowdown has *negligible impact* for you (*the user will not see it*, the extra CPU cost does not imply buying a bigger server, and so on)." 5-7 seconds is *not* a negligible impact that the user will not see. There could perhaps be a special way of encrypting documents for people that are so scared about democracy (= government in all democratic countries) as Michael seems to be, but then let that be a special option for those people to specifially turn on, and let the rest of us have a useful program. Right now, the current version of LibreOffice is completely useless if you want to use password protected documents even once in a while.
i'm afraid this is going to be expensive to fix properly; i was planning to redo ODF encryption so it stores a single ODF package as a zip-in-a-zip which should fix it, but have had no time to work on it, not to mention it will be incompatible of course. btw Word 2010 uses 100k KDF iterations as well for OOXML; i haven't checked what the current version does.
(In reply to jhertel from comment #11) > 5-7 seconds is *not* a negligible impact that the user will not see. I wonder if perhaps using the OpenPGP encryption available from 6.0 on is an option then - it's still experimental, but uses a fixed public/private key pair, that at least does not need to run KDFs for every sub-stream: https://wiki.documentfoundation.org/Development/gpg4libre
I have the same issue. 5.2.4.2 saves quickly with password. 5.4.6.2 and 6.0.5.2 save slow with password and quickly without password.
Intolerably slow. Please make it an option in Options->load/save->General tab (or some other (even some no-ui hidden special config flag (just like firefox has in with it's 'about:config') or a registry/xml/json setting): iteration count: 1024 or 100000.
Saving with the example files is now nearly instant. Can everyone please test again? For Calc files there is still bug 122060 Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 18 April 2019
(In reply to Buovjaga from comment #16) > Saving with the example files is now nearly instant. Can everyone please > test again? Still repro Version: 6.3.0.0.alpha0+ Build ID: 3a5d78365dd172881c16c03e67f2d170ffc6d7d4 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-04-09_22:53:59 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL Which attachment did you use? My example file is working properly at the initial state (even with password set). Slow behavior will be triggered by saving the file with a recent LibO & reopening it (see comment 4)
(In reply to Telesto from comment #17) > (In reply to Buovjaga from comment #16) > > Saving with the example files is now nearly instant. Can everyone please > > test again? > > Still repro > Version: 6.3.0.0.alpha0+ > Build ID: 3a5d78365dd172881c16c03e67f2d170ffc6d7d4 > CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; > TinderBox: Win-x86@42, Branch:master, Time: 2019-04-09_22:53:59 > Locale: nl-NL (nl_NL); UI-Language: en-US > Calc: CL > > Which attachment did you use? My example file is working properly at the > initial state (even with password set). Slow behavior will be triggered by > saving the file with a recent LibO & reopening it (see comment 4) I used both attachments. The summary is "Very slow saving". The step 3 in your comment 4 seems to be something else. Do you really repro the slow saving?
attachment 135887 [details] takes less than 5 seconds to get saved Version: 6.3.0.0.alpha0+ Build ID: c9956772ec0678498515fb60dca41e9a77457f86 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Nothing changed compared to the initial bug report comment 0 I takes +/-5 seconds to save (without progress bar, only locked screen with disappearing cursor) -> Expected 1 second (4.4.7.2) It takes +/-7 seconds to open. Expected 3 seconds So this can be quite annoying; especially with a short auto-save interval.
Created attachment 150894 [details] Perf flamegraph From saving attachment 136012 [details] Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: bcb0c9b4bee1d943d9c60f9d4512dba901f85f54 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 20 April 2019
Dear jhertel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still the same problem in Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: threaded (It's the latest stable version; I won't install a more recent one, and I doubt that will change anything.) It still takes around 7 seconds to save a document I frequently save. 7 seconds is too much in a working situation. It breaks flow and is annoying every single time. I save often, preferably every time I finish a paragraph or stop to think in my writing. The pause of less than a second in 5.2.5 was not a problem. 7 seconds is. While high security can be fine, it is always a balance. In this case, it is too much. We still *at least* need a way to indicate per document how secure we want the saving to be, so it can be adjusted down to a save time that is acceptable for the specific user in the specific situation.
I didn't notice any added delay when I tested in a Win 10 virtual machine with 7.1 and 7.2.
(In reply to Buovjaga from comment #24) > I didn't notice any added delay when I tested in a Win 10 virtual machine > with 7.1 and 7.2. Added delay? Added to what? What did you notice, when you did what, and with what document?
(In reply to jhertel from comment #25) > (In reply to Buovjaga from comment #24) > > I didn't notice any added delay when I tested in a Win 10 virtual machine > > with 7.1 and 7.2. > > Added delay? Added to what? What did you notice, when you did what, and with > what document? Tested with the steps and file in comment 4, but in the dev chat Michael told me I should test with a file containing hundreds of images to really notice the slowness.
(In reply to Buovjaga from comment #26) > Tested with the steps and file in comment 4, but in the dev chat Michael > told me I should test with a file containing hundreds of images to really > notice the slowness. That sample is based on you're power horse of machine ;-) If you're on older (or modern low end) hardware this surely more noticeable and you really don't need hundreds of images
This makes encryption for anyone writing Math or Physics or other sciences: any formula you enter , even small ones such as "x<6^2" , counts as an image, and after 10 pages, it will take such an enormous time that you will disable encryption. In my case it is 104 seconds for a Intel(R) Core(TM) i7-10510U CPU. There is a simple but effective solution: do not use a different salt for the encryption of each image.
I confirm that with LibreOffice 7.1.4.2, using password protection in Calc results in slow load and save operations. A 250 KB Calc file with a password takes me 8 seconds to save, compared to <1 second when I remove the password. This is so slow that when Calc autosaves, my OS (Fedora 34) notices how unresponsive Calc is and pops up a window asking if I want to force quit it or wait.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3b347664b26d58d44f685a607a5e6d10dff89cd4 tdf#105844 package,sfx2: wholesome ODF package wrapping encryption It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f0fda7ad2236f478fea396a23d4f982e5fc37e68 tdf#105844 offapi,package,sfx2,xmlsecurity: add AEAD w/ AES GCM It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/1fbad81c1e28fae31c655c637a513405c3e62317 tdf#105844 offapi,package,sfx2,xmlsecurity: add AEAD w/ AES GCM It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/09f23a3dc5cd571df347cba9b003195de35f3ddd tdf#105844 package,sfx2: remove checksum infoleak when using AEAD It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/309558858d2b37cbad04b3000391ad9ba570708d tdf#105844 package,sfx2: remove checksum infoleak when using AEAD It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/91f35f22f0447769c08ca89e27a39b40df18fffa tdf#105844 package: remove root document from manifest ... It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fb9c58a2f32c352e44ffa30e721ef796dc591d33 tdf#105844 package: check for unexpected zip entries on loading ... It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d2218690382374f3962de014b151dbac84a1446 tdf#105844 sfx2: add another consistency check It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c6c51663479fa036f70b182b5892a23235bbde5f tdf#105844 package: increase PBKDF2 iterations for wholesome ODF encryption It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/c9f68922a4dd058da5fe885ff030b02f876e8b79 tdf#105844 package: remove root document from manifest ... It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/79d9396911afb5edbaeddf2a18759d100e4e825a tdf#105844 package: check for unexpected zip entries on loading ... It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/f738ef21a660d6ef736aeab538a5fe063666f2f1 tdf#105844 sfx2: add another consistency check It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/5303dde8a7c2c09b7104f2c099f879d9273438cb tdf#105844 package: increase PBKDF2 iterations for wholesome ODF encryption It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f512aaa6c39390a5a0eb1d1e37f070127d068a4 tdf#105844 offapi,package,sfx2: use Argon2 for wholesome ODF encryption It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/4995e0669da0e499743b21c60da1ca8b14a1c78c tdf#105844 offapi,package,sfx2: use Argon2 for wholesome ODF encryption It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/401e9408d14dc2b9d07183a04c223831a59f71a3 tdf#105844 argon2: add vcxproj files for WinARM64 builds It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/2e8b59608471ab6c62a2e9c851dbe2b28fbd9804 tdf#105844 argon2: add vcxproj files for WinARM64 builds It will be available in 24.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
=== ODF Wholesome Encryption === A new mode of password-based ODF encryption has been implemented, with the following advantages: * more performant due to deriving a key only once per package * more tamper-resistant with authenticated encryption ('''AES-GCM''') * better hiding of metadata to reduce information leaks * higher resistance to brute forcing using memory-hard '''Argon2id''' key derivation function This is available if Experimental Features are enabled in {{bc|Tools|Options|LibreOffice|Advanced}}. ODF proposal is here: https://issues.oasis-open.org/browse/OFFICE-4153
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bac43054e2997235ce98432bc9cb6c434120e4b2 tdf#105844 package: ManifestImport: handle argon2 attributes in ... It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f1117fbfcd931d4ea2fccfb56f154aa6186d384b tdf#105844 package: ODF wholesome encryption: use package version It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4d6e9d5e155da1dde05233eb87691e2a454162f6 tdf#105844 add test for ODF wholesome encryption with macro signature It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3e9a700091872480dd085f0928d1d30b7d74cfd7 tdf#105844 xmlsecurity: fix test failure on WNT It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/8f5c108297fb4816318172f4c7240438f956bb60 tdf#105844 package: ManifestImport: handle argon2 attributes in ... It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/b955e86071e91c7f6d0047f383f225881db7b417 tdf#105844 package: ODF wholesome encryption: use package version It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/3f9979db2331e9cdf73743cc68a3ce7174ea54fa tdf#105844 xmlsecurity: fix test failure on WNT It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/45f3d436d0a1271b42c22d9244cc24d237c94ff9 tdf#105844 add test for ODF wholesome encryption with macro signature It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #51) > Michael Stahl committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 3e9a700091872480dd085f0928d1d30b7d74cfd7 > > tdf#105844 xmlsecurity: fix test failure on WNT > > It will be available in 24.8.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. I know this is supposed to fix the test failures on WNT but I have the same failures on macOS and this fix didn't solve the issue for me, i.e., the unit test is (still) failing on macOS.
Sorry, to further clarify my comment above, not all tests fail but this one still does: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody finished in: 435ms [_RUN_____] testPreserveMacroSignatureODB::TestBody testPreserveMacroSignatureODB::TestBody finished in: 299ms /Users/yeed/Developer/lode/dev/core/xmlsecurity/qa/unit/signing/signing2.cxx:252: Assertion Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody equality assertion failed - Expected: 1 - Actual : 4
(In reply to Yiğit Akçay from comment #57) > Sorry, to further clarify my comment above, not all tests fail but this one > still does: > > testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody finished in: > 435ms > [_RUN_____] testPreserveMacroSignatureODB::TestBody > testPreserveMacroSignatureODB::TestBody finished in: 299ms > /Users/yeed/Developer/lode/dev/core/xmlsecurity/qa/unit/signing/signing2.cxx: > 252: Assertion > Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody > equality assertion failed > - Expected: 1 > - Actual : 4 Note that you don't necessarily need to run all tests when developing. You can also say make module.check to run the test suites for a particular module (directory).
hmm... looking at https://ci.libreoffice.org/job/gerrit_mac/160260/consoleFull the Mac in jenkins runs: make build unitcheck slowcheck so it also doesn't execute these tests. i wonder if it fails on every Mac but i don't have one to try it...
(In reply to Buovjaga from comment #58) > (In reply to Yiğit Akçay from comment #57) > > Sorry, to further clarify my comment above, not all tests fail but this one > > still does: > > > > testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody finished in: > > 435ms > > [_RUN_____] testPreserveMacroSignatureODB::TestBody > > testPreserveMacroSignatureODB::TestBody finished in: 299ms > > /Users/yeed/Developer/lode/dev/core/xmlsecurity/qa/unit/signing/signing2.cxx: > > 252: Assertion > > Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody > > equality assertion failed > > - Expected: 1 > > - Actual : 4 > > Note that you don't necessarily need to run all tests when developing. You > can also say > > make module.check > > to run the test suites for a particular module (directory). Thank you for the info! (In reply to Michael Stahl (allotropia) from comment #59) > hmm... looking at > https://ci.libreoffice.org/job/gerrit_mac/160260/consoleFull > the Mac in jenkins runs: > make build unitcheck slowcheck > > so it also doesn't execute these tests. i wonder if it fails on every Mac > but i don't have one to try it... Well, if we look into xmlsecurity/Module_xmlsecurity.mk line 27-28 we can see that the signing and signing2 unit tests are only added to the subsequentcheck target. Not sure if it is an oversight to leave out the subsequentcheck target in jenkins, but following https://wiki.documentfoundation.org/Development/lode#Supported_Platforms suggests executing make check, which gets translated to unitcheck slowcheck and subsequentcheck targets.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2048db4dc8ee6edb231a9109257846975a6f7834 tdf#105844 unotest,xmlsecurity: fix tests on MacOSX It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/93444f3aaeb2c082abe52f3842674ddc7654426c tdf#105844 unotest,xmlsecurity: fix tests on MacOSX It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #62) > Michael Stahl committed a patch related to this issue. > It has been pushed to "libreoffice-24-2": > > https://git.libreoffice.org/core/commit/ > 93444f3aaeb2c082abe52f3842674ddc7654426c > > tdf#105844 unotest,xmlsecurity: fix tests on MacOSX > > It will be available in 24.2.1. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Please see: 159521 – LibreOffice Calc 24.2.0.3 (X86_64) ODS files saved with new experimental password protection feature causes data loss https://bugs.documentfoundation.org/show_bug.cgi?id=159521 And perhaps also see if these can possibly be related, or if you can determine the cause/remedy: 159512 – LibreOffice Calc ODS files saved with passwords under 7.6.4 (X86_64) cannot be opened in 24.2.0.3 (X86_64). https://bugs.documentfoundation.org/show_bug.cgi?id=159512 159519 – LibreOffice Calc 24.2.0.3 (X86_64) ODS files saved with passwords can be opened without any password https://bugs.documentfoundation.org/show_bug.cgi?id=159519
(In reply to Commit Notification from comment #62) > Michael Stahl committed a patch related to this issue. > It has been pushed to "libreoffice-24-2": > > https://git.libreoffice.org/core/commit/ > 93444f3aaeb2c082abe52f3842674ddc7654426c > > tdf#105844 unotest,xmlsecurity: fix tests on MacOSX > > It will be available in 24.2.1. > ... I'm a bit confused as to the version number cited above. According to the following document, it looks like the patch was included in formal releases (non-dailies) starting in 24.2.0 Beta 1 (and then in RC1 & RC2) and then was released with RC3 which became the general release 24.2.0.3. Is this correct? https://wiki.documentfoundation.org/Releases/24.2.0/Beta1 If so, from where does the 24.2.1 version number originate?
(In reply to Jimmy from comment #64) > If so, from where does the 24.2.1 version number originate? That will be the next 24.2 release. The commit should be part of the next daily for the 24.2 branch, which is not the same daily for the current master branch.
(In reply to ady from comment #65) > (In reply to Jimmy from comment #64) > > If so, from where does the 24.2.1 version number originate? > > That will be the next 24.2 release. The commit should be part of the next > daily for the 24.2 branch, which is not the same daily for the current > master branch. Thanks. Is the commit mentioned in the following post included in 24.2.0.3? https://bugs.documentfoundation.org/show_bug.cgi?id=105844#c47
(In reply to Commit Notification from comment #61) > Michael Stahl committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 2048db4dc8ee6edb231a9109257846975a6f7834 > > tdf#105844 unotest,xmlsecurity: fix tests on MacOSX > > It will be available in 24.8.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. I ran the test with your patch, it passes now. Thanks for the fix!
(In reply to Jimmy from comment #66) > (In reply to ady from comment #65) > > (In reply to Jimmy from comment #64) > > > If so, from where does the 24.2.1 version number originate? > > > > That will be the next 24.2 release. The commit should be part of the next > > daily for the 24.2 branch, which is not the same daily for the current > > master branch. > > Thanks. Is the commit mentioned in the following post included in 24.2.0.3? > > https://bugs.documentfoundation.org/show_bug.cgi?id=105844#c47 that comment does not mention a commit. the only commit that changes office code (not just tests) that is not in 24.2.0.3 is this one, which should have an effect only when opening a document: https://git.libreoffice.org/core/commit/b955e86071e91c7f6d0047f383f225881db7b417