Bug 162823 - A password-protected Basic library in an ODB created in 24.2 is lost after re-save in 24.8
Summary: A password-protected Basic library in an ODB created in 24.2 is lost after re...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
24.8.0.3 release
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:25.2.0 target:24.2.7 target:24...
Keywords: bisected, dataLoss, regression
Depends on:
Blocks:
 
Reported: 2024-09-06 13:19 UTC by Mike Kaganski
Modified: 2024-09-17 16:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
An empty ODB with a password-protected Basic library (password 1234) (6.35 KB, application/vnd.sun.xml.base)
2024-09-06 13:19 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2024-09-06 13:19:55 UTC
Created attachment 196283 [details]
An empty ODB with a password-protected Basic library (password 1234)

Open the attached ODB (created in 24.2.0). Confirm macros. Run the "Main" in "Library1/Module1", which shows a message box. Now Save As the ODB to a new filename.

If the save is done in 24.8, after reopening the new ODB, there is no module and macro in the library.
Comment 1 raal 2024-09-06 13:30:19 UTC
Confirm with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 10363c80eb3fd0637d91714fe977de77b43d3aa3
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 2 Mike Kaganski 2024-09-06 14:47:15 UTC
Regression after efae4fc42d5fe3c0a69757226f38efc10d101194
Comment 3 Mike Kaganski 2024-09-06 15:45:57 UTC
A suspicion is that ZipPackageStream::TryToGetRawFromDataStream creates some inconsistent data (the entry that fails the "mismatching DEFLATE/STORE" check in ZipFile::readLOC_Impl has "dummy" path).
Comment 4 Mike Kaganski 2024-09-06 16:02:41 UTC
A "from scratch" reproduction in master:

1. Create a new Base document (no matter which database; e.g., embedded Firebird, or HSQLDB);
2. Tools->Macros->Organize Macros->Basic;
3. [Organizer];
4. "Libraries" tab -> Location: New Database.odb
5. [New]->"Library1"->[OK]
6. [Password]->"1234"->[OK]
7. "Modules" tab -> New Database.odb -> Library1/Module1 ->[Edit]
8. Add something to Main - e.g., MsgBox "foo"
9. Save

=> it silently does not save; the "unsaved" mark stays on Save toolbar button of the Base module
Comment 5 Mike Kaganski 2024-09-07 11:21:37 UTC
https://opengrok.libreoffice.org/xref/core/package/source/zipapi/ZipOutputStream.cxx?r=d33d5928#writeLOC

    // If it's an encrypted entry, we pretend its stored plain text
    if (bEncrypt)
        m_aChucker.WriteInt16( STORED );

Looks like this is the problem. Michael, could you advise, if it's safe to drop this condition here, or should we relax the check in the "mismatching DEFLATE/STORE" check in ZipFile::readLOC_Impl ?
Comment 6 Commit Notification 2024-09-13 09:33:03 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/33d55465d9f81863b88d649a46353cc4d19cd253

tdf#162823 package: fix loss of ODF encrypted basic macros

It will be available in 25.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.
Comment 7 Michael Stahl (allotropia) 2024-09-13 10:40:32 UTC
no, that would be wrong, it's actually required by ODF package specification:

    Each file entry that is encrypted shall be compressed with the “deflate” algorithm before being encrypted. Encrypted file entries shall be flagged as 'STORED' rather than 'DEFLATED' in the Zip file's central directory. The size of the encrypted file should replace the real size value in the file entry's central directory records, its local file header and the data descriptor, if any. The original uncompressed, unencrypted size shall be contained in the manifest:size 4.16.13 attribute of the <manifest:file-entry> 4.3 element for the file entry.

i'm guessing this is so that other Zip tools don't try to inflate the entry, which will fail due to the encryption.


fixed on master
Comment 8 Commit Notification 2024-09-17 03:59:38 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/d290716ba140cdb3282cd542d1cd6f12709ae06f

tdf#162823 package: fix loss of ODF encrypted basic macros

It will be available in 24.2.7.

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.
Comment 9 Commit Notification 2024-09-17 16:47:14 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/2aba8457d72a709411ea892e9561cb5442795846

tdf#162823 package: fix loss of ODF encrypted basic macros

It will be available in 24.8.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.