Description: After the fix of bug #106843 it is supported to lock change tracking in DOCX files, but removing that password is still not possible. Steps to Reproduce: 1. Open attachment #148094 [details] 2. Go to File – Properties – Security 3. Click the Unprotect button. The password of that document is test Actual Results: Password is not accepted. Expected Results: Password should be accepted Reproducible: Always User Profile Reset: No Additional Info: LibreOffice details: Version: 6.4.0.0.alpha1+ (x86) Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL
Created attachment 155740 [details] Screenshot of the problem in Writer.
I confirm it with Version: 6.4.0.0.alpha1 (x64) Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
Commit description: tdf#128744 sw DOCX: unprotect change tracking with verification Unprotect change tracking only by password verification instead of 1) unprotecting without the password or 2) rejecting the correct password. I.e. now 1) clicking on Record changes icon of Track Changes toolbar or Edit->Track Changes->Record asks for a password, and 2) Unprotect Record changes on Security page of File->Properties... accepts the correct password with disabling record changes. Show also "Invalid password!" dialog disabling Record Changes by its icon or menu option, like Properties... dialog window does, if the password is invalid. Note: Still allow to unprotect OpenDocument export of a protected OOXML import document, because that doesn't contain the original password info, only a dummy RedlinePassword. (OpenDocument exports protect Track Changes with the simple RedlineProtectionKey configuration setting, so it's not possible to map the OOXML password info to OpenDocument without extending this.) Follow-up to commit d416250f4f1766e2d596ea3feef6a94b7adf29f4 "tdf#106843 DOCX: forbid disabling protected Record Changes". See also commit bfd7730f4cf002a79dc9c02c23286850fee3f12a "tdf#89383 DOCX import: fix permission for editing".
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/28c31ba12567f66ccb6a334fd21af10880f4a33b tdf#128744 sw DOCX: unprotect change tracking with verification It will be available in 7.4.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.
Hi László, I think this is worth it to be mentioned in the release notes: https://wiki.documentfoundation.org/ReleaseNotes/7.4
(In reply to Xisco Faulí from comment #5) > Hi László, > I think this is worth it to be mentioned in the release notes: > https://wiki.documentfoundation.org/ReleaseNotes/7.4 Hi Xisco, Thanks for the suggestion. I've added here: https://wiki.documentfoundation.org/ReleaseNotes/7.4#Unlock_protected_change_tracking_by_password_verification Best regards, László
For me bug is still present with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 83d0f2eebae41d431d9a5bfd1a918523977752d0 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL (tested with steps from comment 0) => REOPENED
(In reply to Dieter from comment #7) > For me bug is still present with > > Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: 83d0f2eebae41d431d9a5bfd1a918523977752d0 > CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL > > (tested with steps from comment 0) > > => REOPENED @Dieter: According to the build ID 83d0f2eebae41d431d9a5bfd1a918523977752d0, your LO test build is from 26 Apr (see https://gerrit.libreoffice.org/c/core/+/126501), but this bug was fixed on 9 May. Could you check it with a newer build, which contains the fix, please? Newer builds: https://dev-builds.libreoffice.org/daily/master/
(In reply to László Németh from comment #8) > @Dieter: According to the build ID 83d0f2eebae41d431d9a5bfd1a918523977752d0, > your LO test build is from 26 Apr (see > https://gerrit.libreoffice.org/c/core/+/126501), but this bug was fixed on 9 > May. Thank you for your hint. I've just recognized, that installation of a more recent version failed. But also with the following version problem is still present: Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community Build ID: b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL => REOPENED
Created attachment 180133 [details] A test document with the password "test"
(In reply to Dieter from comment #9) > (In reply to László Németh from comment #8) > > @Dieter: According to the build ID 83d0f2eebae41d431d9a5bfd1a918523977752d0, > > your LO test build is from 26 Apr (see > > https://gerrit.libreoffice.org/c/core/+/126501), but this bug was fixed on 9 > > May. > > Thank you for your hint. I've just recognized, that installation of a more > recent version failed. But also with the following version problem is still > present: > > Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community > Build ID: b871abad383583f02eb49c7e49aeae01f6941072 > CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL > > => REOPENED @Dieter: Thanks for testing! It seemed for me, that the test document mentioned in the report has a different password, not "test". I've attached a new one (the unit test document of the patch), where I copied an MSO generated "test" password of locked editing to lock changeTracking. Otherwise, it would be fine to check both test documents in MSO 2019, where this encryption is supported.
(In reply to László Németh from comment #11) > @Dieter: Thanks for testing! It seemed for me, that the test document > mentioned in the report has a different password, not "test". I've attached > a new one (the unit test document of the patch), where I copied an MSO > generated "test" password of locked editing to lock changeTracking. > Otherwise, it would be fine to check both test documents in MSO 2019, where > this encryption is supported. @Dieter: the newly attached file handled by LibreOffice and Word correctly, too. But it seems, MSO 2019 uses some "Legacy Password Hash Algorithm" or other tricks, according to https://stackoverflow.com/questions/65877620/open-xml-document-protection-implementation-documentprotection-class, so we are going to file a new bug for the older test document, too. Thanks for your verification!
(In reply to László Németh from comment #10) > Created attachment 180133 [details] > A test document with the password "test" VERIFIED with that document and Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community Build ID: b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Lásló, thanks for fixing it!
(In reply to Dieter from comment #13) > (In reply to László Németh from comment #10) > > Created attachment 180133 [details] > > A test document with the password "test" > > VERIFIED with that document and > > Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community > Build ID: b871abad383583f02eb49c7e49aeae01f6941072 > CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL > > Lásló, thanks for fixing it! Dieter, thanks for the verification!