Opening a XLSX file or
Saving as XLSX file and tick the "Save with password" option.
Entering the password without watching the input line twice.
Document is now encrypted, but the password will fail if it consists of more than 15 characters. Copy pasting a more than 15 character password will yield a notice that the password was truncated. What's missing is a notification to this limit, better yet get rid of the limit. Excel 2010 encrypts XLSX files woth passwords above 15 characters and LibreCalc can open them fine, too. So why the limitation in regard to password length?
Thank you for reporting this issue.
I can reproduce and confirm the described behaviour.
Windows 10 Pro, Version 1511 (OS Build 10586.36)
Version: 18.104.22.168 Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: de-DE (de_DE)
1. Create new Calc document
2. File -> Save As
3. Set "Save as Type" to XLSX
4. Tick "Save with Password"
5. Click Save
6. The appearing password textboxes have a 15 character limit and give no visual or audible warning when addidional keys are pressed
In contrast, saving in ODS file format does not have a 15 character limit, which could be confusing when this behaviour is expected. Since it can lead to data becoming inaccessible I'm both setting this issue to NEW and elevating it to MEDIUM/CRITICAL.
If there is going to be a limit LO should let the user keep typing but show a message that the password is too long and not let them save until its been shortened rather then just not taking in any more input which the user might not notice.
Also set OS to all because it affects linux too.
This should be checked to find out if it's a regression. Also, sorry for the noise but I'm lowering to Major.
Reason: Critical really should be kept for the worst bugs that affect the project. Worst means, serious data loss/crashes for a *significant portion of our user base.*" Although this might lock out data - this would be in incredibly rare cases....when? Well: (1) when a user password protects which is already in a very small minority of our user base; and then (2) when that password is >15 characters long; and finally (3) when the user isn't aware of this limitation. A relatively fast search of the bugs will come up with this hit....if it's not a regression, proof of how rare it is comes with the fact that it has never been reported before :)
By default critical and major bugs go to "high" but I'm leaving as "medium" due to the above rationale - the very small number of potentially affected users means lower priority in an objective standard.
No regression, it's been like this since the beginning of time.
There's indeed 15 char length limit on passwords in LO, restricted to MSO formats. I can't quite see why as it's impossible to search commit history so far back into the past.
Likely because of this: https://msdn.microsoft.com/en-us/library/dd772916%28v=office.12%29.aspx It looks like such limit used to exist in binary MSO formats (.doc, .xls)
Couldn't find any info on password limits in OOXML standard, just that this 15 char limit exists in MS Excel on Mac platform: https://support.office.com/en-us/article/Require-a-password-to-open-or-modify-a-workbook-10579f0e-b2d9-4c05-b9f8-4109a6bce643 probably independent of file format.
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice
(5.2.5 or 5.3.0 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
*** Bug 109175 has been marked as a duplicate of this bug. ***
See also MR: https://gerrit.libreoffice.org/#/c/54193/
I've got no feedback for merge request, so I'm not working on this issue anymore.
Feedback was given in Gerrit by Mike on May-22 but noreply+66619/redacted didn't follow-up on the comments.