...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It is only impossible during normal package parsing because of the added
consistency checks, but the inconsistency can happen during recovery.
Kind of arbitrary which size is used then?
Change-Id: I31ce9ae8b6fe3d1ca50a118ae6c1feaaaffe17ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191455
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
This would be reported on reading as an 8-byte gap at the position where
a 32-bit DD for the entry would end.
The problem is that if flag bit 3 is set, and the uncompressed size
exceeds 2^32, writeDataDescriptor() will write 8-byte sizes, but the
Zip64 extension header is missing - the latter should also write 0 even
though the APPNOTE doens't appear to require it.
4.3.9.2 [...] When extracting, if
the zip64 extended information extra field is present for
the file the compressed and uncompressed sizes will be 8
byte values.
Also make sure that the ZipEntry nSize member actually contains the
uncompressed size, which is somewhat tricky, but is required in
writeLOC() to check if Zip64 is needed. (Assume that the DEFLATEd size
is never larger than uncompressed, which is true for every XML file).
Change-Id: I611e6ffda12d8e6953e9306dc4a4407be8e725a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191185
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
It makes no sense to insist on a random type, only to reinterpret_cast
it everywhere. An opaque void fits the case perfectly.
Change-Id: If945b1c59d98c5f561350db649f29fe8036e7cdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186982
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit a6ad198d09 made the size read
from the grabber wrong for the last chunk: it wasn't decreased to
the remaining size, but was still equal to nBlockSize. The grabber
could read past the chunk, and the CRC was wrong. No idea why did
that only hit this file - it seemed that any file larger than 32K
and that was stored (i.e., any image) would trigger that path?
Change-Id: I980dd701e54c4ed565173b5b90ed301bf9b5f719
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186241
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Integrate build system support for the Zstandard (zstd) library and
implement the corresponding C++ decompression stream classes, enabling
future use of zstd-compressed streams in ZIP packages.
Build System (Part 2a):
- Add `--with-system-zstd=[yes|no|auto]` configure option.
- Implement system library checks (`zstd.h`, `libzstd`) in configure.ac.
- Define rules (`external/zstd/*`) for downloading and building the
internal zstd static library (decompression components only).
- Set up necessary CFLAGS/LIBS via configure.ac and config_host.mk.in.
- Configure linking via RepositoryExternal.mk (`gb_LinkTarget__use_zstd`).
- Update auxiliary files (download.lst, distro-configs, etc.).
C++ Implementation (Part 2b):
- Implement `InflateZstd` (in `include/package`) and `InflaterBytesZstd`
(in `package/inc`) inheriting from `Inflater`/`InflaterBytes`.
- Use the zstd streaming API (`ZSTD_decompressStream`) following the
existing single-call pattern established by the zlib implementation.
- Manage context (`ZSTD_DCtx`) and input buffer (`ZSTD_inBuffer`) state.
- Handle errors, stream completion (`ret == 0`), and input truncation.
- Add new classes to `package/Library_package2.mk` build.
This completes the infrastructure for zstd decompression support.
The next step (Part 2c) involves adding logic to select the
appropriate Inflater based on the ZIP entry's compression method ID.
Change-Id: Ia673f3f19b6a751ba5225394fcf8c3f145c4ae63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184243
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Refactor ZIP decompression classes (Inflater, InflaterBytes) to support multiple decompression algorithms, enabling future Zstandard
support.
Make Inflater and InflaterBytes abstract base classes defining a common interface. Move the original zlib/Deflate logic into new derived classes InflateZlib and InflaterBytesZlib.
Update usage sites to instantiate the *Zlib variants via unique_ptr to the base class, preserving existing functionality. Move header files to standard locations (include/package, package/inc) and update includes and build files.
This pure refactoring prepares the codebase for adding Zstandard (zstd) decompression. Correct a minor logical bug in the ZipFile::getSizeAndCRC loop condition.
Change-Id: I9be3c02946e29eb2dae09f500eb47d8a4261af22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183504
Reviewed-by: Devansh Varshney <varshney.devansh614@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
The PK78 signature is optional, and if the sizes in the local file
header are 0 then without the DD the recovery won't do anything useful.
If the latest local file header has the DD bit set in flags, then try to
find the DD before the next thing that has a PK?? signature.
Change-Id: I149a87805f7bcb6216fc909c20ece600ce77956d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183722
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
... compressed size = 0.
The problem is that vector::data() on a vector of size 0 returns
nullptr, and osl_readFile into a nullptr buffer returns E_INVAL, which
causes an exception to be thrown.
Catch the exception, so that there is a chance to read the values from
the data descriptor instead.
(regression from commit 32cad89592
and/or commit a6ad198d09)
Change-Id: I9b2d9a930997146faf224d8033955b142fe93f58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176289
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
https://rzymek.github.io/post/excel-zip64/ claims that it's sufficient
for the version number to be 45 (4.5 - File uses ZIP64 format
extensions) for Excel to read a zip entry's data descriptor as
Zip64, while the Zip APPNOTE seems to require a zip64 extended
information extra field to be present (see 4.3.9.2).
Let's try to use the "version needed to extract" to be able to read
zip files produced by Apache POI Zip64Mode.Always.
Change-Id: I20f10471e3a85eb42d21c0cb08e36e345ef8fc9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176211
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
1. Accept 0xFFFF as nEndDisk/nEndDirDisk - the Zip APPNOTE says that
values that don't fit into 16 bits SHOULD be 0xFFFF but it doesn't
prohibit values that do fit (like, uhm, 0) to be written as 0xFFFF
(regression from commit ca21cc985d)
2. Fix misuse of o3tl::make_unsigned - it requires non-negative value,
just do signed compare instead
3. Fix bad conversion from pointer to optional in
ZipFile::readExtraFields() which effectively prevented the offset
from being read
(regression from commit efae4fc42d)
Change-Id: Ib5e7776a30834e507b297fb28266b5489d1ab68d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174898
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... duplicates; the directory names of AutoCorrect entries are
user-editable, so this needs to be supported.
AutoCorrect uses an ODF package because the ODF document loading code
requires the ODF document to be in an ODF storage with a MediaType
property.
AutoCorrect writes an empty mimetype file, and if such is present in an
.odt file that is being loaded, existing checks will detect it as
corrupted, so we can use this to check that the file is an AutoCorrect
file and turn off the case-insensitive check.
(regression from commit 4833f13124)
Change-Id: I43887f7dad0c8cbb465b4c0f1c38bcc3244a7675
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173477
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
since:
commit a6ad198d09
CommitDate: Tue Aug 27 09:10:04 2024 +0200
tdf#158556 use more comphelper::ByteReader
reserve doesn't make any guarantees about validity of subsequent data()
Change-Id: Ifb155b349b15103c367d841bbef7d5d0e2cbb5f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173371
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
at which point nPos is 0 on entering this test.
If the buffer does not start with PK\x5\x6 then nPos is decremented
before checking against 0, so nPos is -1 and doesn't throw as an
unhandled .zip.
Change-Id: I4a7fed6e863582324945a75bc077f6346ddd5c23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173208
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The problem is that there is a ZipEntry ZipPackageStream::aEntry which
does not necessarily correspond to the values read from the Zip central
directory, because of a call to ZipPackageStream::setSize() in
ZipPackageStream::successfullyWritten() to override nSize and nMethod
for encrypted entries.
This triggers the consistency checks in readLOC(), where this aEntry is
passed.
Refactor things so that ZipPackageStream::aEntry and thus hopefully all
ZipEntry instances correspond to the Zip file's central directory.
For encrypted entries, store the decompressed size (which is read from
manifest.xml) in m_nOwnStreamOrigSize and pass it as a separate
parameter to the ZipFile functions that need it, and ultimately to
XUnbufferedStream, resolving multiple TODO comments.
(regression from commit efae4fc42d)
Change-Id: Ib6ea32595c6027b98da9196a2e2bd0a99b62a983
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173273
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
used to be:
Sequence<sal_Int8> aFileName;
aGrabber.readBytes(aFileName, aEntry.nPathLen);
aEntry.nPathLen = aFileName.getLength();
so aEntry.nPathLen ended up as the the count of read bytes actually
read when aEntry.nPathLen was requested
Change-Id: I50b2c4c7be086e4b846998ee52fbabed6159279d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172508
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
... data descriptor; only allow it for encrypted ODF entries, which
requires reading the manifest first.
Change-Id: If36d31a4cb93e7af78f48be3ed899ad9d9bb28f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171911
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Stephan Bergmann