Bug 329579

Summary:	Extracted file is corrupt
Product:	[Frameworks and Libraries] frameworks-karchive	Reporter:	Fabian Vogt <fabian>
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED FIXED
Severity:	major	CC:	elvis.angelaccio, faure, kdelibs-bugs-null, mail
Priority:	NOR
Version First Reported In:	5.51.0
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:	https://invent.kde.org/frameworks/karchive/-/commit/e20f869437fc4dd979e36e8f18403a03920b148e	Version Fixed/Implemented In:
Sentry Crash Report:

Description Fabian Vogt 2014-01-03 21:37:13 UTC

The TI nspire OS files are valid zip files and can be extracted by any zip utility such as unzip. But if I copy-paste zip:/file.zip/boot2.img to extract it, the resulting uncompressed file is corrupt. There is additional stuff at the beginning and at the end.
Example download: http://education.ti.com/de/deutschland/software/details/en/0607F21D07B14ACB9EE85E57A9C30EDA/ti-nspirecxcas_os

Reproducible: Always

Steps to Reproduce:
1. Download http://education.ti.com/de/deutschland/software/details/en/0607F21D07B14ACB9EE85E57A9C30EDA/ti-nspirecxcas_os
2. Open in dolphin with zip:/
3. Copy boot2.img
4. Compare with the result of "unzip *.tcc boot2.img"
5. The files differ



Ark works (as expected).
"unzip" says "63 extra bytes at beginning or within zipfile".
Maybe it's an issue that the header isn't word-aligned?

Comment 1 Julian Steinmann 2018-07-22 16:44:33 UTC

I can reproduce this behavior using KDE Frameworks 5.48, relocating to kio-extras.

Comment 2 David Faure 2018-08-01 08:20:28 UTC

Probably a KArchive bug though ;)

Comment 3 Bug Janitor Service 2025-04-02 16:02:45 UTC

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/karchive/-/merge_requests/111

Comment 4 Stefan Brüns 2025-04-16 15:34:00 UTC

Git commit e20f869437fc4dd979e36e8f18403a03920b148e by Stefan Brüns.
Committed on 16/04/2025 at 15:31.
Pushed by bruns into branch 'master'.

kzip: Fix position calculation for archives with prepended arbitrary data

There are two variants of non-ZIP data before the first Local File Header.
Either with offset in the Central Directory reflecting the actual
position, i.e. the first entry offset in the CD will point just after the
additional non-ZIP header instead of 0. This is the case for e.g.
self-extracting archives from WinZIP.

The other is just a concatenation of non-ZIP data and a regular ZIP file,
i.e. the first entry in the CD will contain an offset value of 0.

unzip (Info-ZIP) and bsdunzip (libarchive) accept both variants (unzip -v
provides a warning - "warning [xxx.zip]:  61 extra bytes at beginning or
within zipfile"), libzip requires an explicit offset (-o 61) for the
latter.

Verify if the (adjusted) local file header offset in the Central
Directory match the seen positions, bail out otherwise. Provide a
warning similar to unzip in case there is extra data.

Limit the initial header search to the first 4 MByte (previously
unlimited). Also provide a more specific error message.

M  +26   -0    autotests/karchivetest.cpp
M  +1    -0    autotests/karchivetest.h
M  +27   -4    src/kzip.cpp

https://invent.kde.org/frameworks/karchive/-/commit/e20f869437fc4dd979e36e8f18403a03920b148e