V668 There is no sense in testing the 'm_pRelStorElement->m_xStorage' pointer against null, as the memory was allocated using the 'new' operator. The exception will be generated in the case of memory allocation error.
Change-Id: Ie195de78b48c3766ef08a2d3666f778f75d2ca6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176596
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Since
commit a6ad198d09
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 17 13:19:54 2024 +0200
tdf#158556 use more comphelper::ByteReader
V1022 An exception was thrown by pointer. Consider throwing it by value instead.
Change-Id: I9218d79097975e47822f48838472ca2096d527d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176398
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
... 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
V1037 Two or more case-branches perform the same actions. Check lines: 50, 53
Change-Id: I909c0b5b219d5868a1a0197314f499e0253b3293
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175388
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
Bugdoc has a data descriptor on a folder entry, which is very odd and
entirely pointless. Which is also the first entry, so it's an invalid
ODF package anyway.
ZipPackageFolder throws UnknownPropertyException for "WasEncrypted",
which results in General I/O error, but we want to ask the user if the
file should be opened in recovery mode.
(regression from commit 32cad89592)
Change-Id: Iafe610d507cf92d2fd2e9c3040592c3e638a30dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174889
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Fallbacks are only useful if an existing file is imported.
It looks like it might have been possible to hit this case by storing a
new document as ODF 1.1, and that sets m_bIsEncrypted but not
m_oImportedAlgorithms (as Mike Kaganski pointed out), haven't tried it.
Change-Id: Ia82c2e43372f50aa4e7ad9c2c62878986295c815
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173551
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
The problem is that ZipPackageStream::GetEncryptionData() doesn't handle
the checksum correctly; what is required here is *no checksum* but the
check of m_oImportedChecksumAlgorithm results in calling
m_rZipPackage.GetChecksumAlgID() instead, so it ends up in invalid
situation and assert:
package/source/zippackage/ZipPackageStream.cxx:656: virtual bool ZipPackageStream::saveChild(): Assertion `xEncData->m_nEncAlg != xml::crypto::CipherID::AES_GCM_W3C' failed.
Refactor this so all the imported algorithm identifiers are in a struct
in a std::optional member.
(regression from commit 09f23a3dc5)
Change-Id: I4b705520cd9bc800ce3c8611f8ad01a1e1008929
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173342
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Not possible yet to use std::make_unique_for_overwrite, baseline
compiler versions are not ready.
Change-Id: Ie14ac5210fa63dcdc7755bb8c722800a877acd44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173381
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
when we are going to write to data()
Change-Id: I1412849911d7bbb990a5f0d712f3ac51a5fea163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173373
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
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
we can allocate these buffers one caller up in ReadCEN and then re-use
them
Change-Id: I07e98168ee2884286f4a1c281acd86e365416149
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172481
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
which avoids a ton of temporary uno::Sequence being created
Change-Id: I237bb69395f692bb0272ca0daec05b81af828e01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171968
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
it is only used from one place, and that place already locks a mutex
around all usage
Change-Id: I85a8d89220bee7806db5457d69cfcf2f11c1734d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171947
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... 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>
