Bug 160779 - Fileopen XLSX: protectedRange without name and sqref is invalid
Summary: Fileopen XLSX: protectedRange without name and sqref is invalid
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://c-rex.net/samples/ooxml/e1/Pa...
Whiteboard:
Keywords: filter:xlsx
Depends on:
Blocks: XLSX-Corrupted
  Show dependency treegraph
 
Reported: 2024-04-22 11:28 UTC by Timur
Modified: 2024-11-20 03:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample XLSX with short-hand protectedRange (19.54 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2024-04-22 11:28 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2024-04-22 11:28:55 UTC
Created attachment 193800 [details]
Sample XLSX with short-hand protectedRange

protectedRange of XLSX is not supported in LO and that is bug 134920.
XLSX files should be kept proper, though and they normally are.
There is a possibility of short-hand version of range address in file (sqref="10:131" instead of sqref="A10:XFD131"), that is read by MSO. 
Sample is attached.
LO opens it but saves wrongly. There is https://gerrit.libreoffice.org/c/core/+/166269 for that. 

This ticket is about applying the OOXML Standard that says that child attributes name and sqref of protectedRange are required. 
Without it, MSO says that XLSX is corrupted, and LO should also do it.
That would safeguard XLSX in saving, so that potential wrong save is seen on next fileopen.
Comment 1 Stéphane Guillou (stragu) 2024-05-23 07:01:47 UTC
I resaved attachment 193800 [details] with:

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 101b08fe1ec77ffe8c1a9b2b8f9f20884269a1ed
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Reload in LO shows no warning, but opening it in MS 365 neither.

I see that a29d91ac403f1ed431ca95b8b9c290bd354c3ae7 and cfb913db1b2024f8ff6a55f45742b303107a1924 are both merged already.
Am I missing something? Do you have updated steps to illustrate how the file gets corrupted?

Relevant part of OOXML spec[1]:
<complexType name="CT_ProtectedRange">
	<attribute name="password" type="ST_UnsignedShortHex" use="optional"/>
	<attribute name="sqref" type="ST_Sqref" use="required"/>
	<attribute name="name" type="ST_Xstring" use="required"/>
	<attribute name="securityDescriptor" type="xsd:string" use="optional"/>
</complexType>

[1]: https://c-rex.net/samples/ooxml/e1/Part4/OOXML_P4_DOCX_protectedRange_topic_ID0ERYC5.html
Comment 2 QA Administrators 2024-11-20 03:16:49 UTC
Dear Timur,

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