d77c99ebc3 changed MappedFile to return a
bogus zero-length mapping on failure rather than nullptr. None of the
calling code was changed, though, and it seems like doing so would be a
bad idea. Revert that part of the change.
Add missing tests, and tidy up some of the logging. Also remove
single-use or obfuscatory constants from the tests.
The new "empty.zip" was created by using zip(1) to create a zip file
with one entry, then using `zip -d` to remove it.
The new "zero-size-cd.zip" was created by using zip(1) to create a zip
file containing a single empty file, and then hex editing the two byte
"size of the central directory" field in the "end of central directory
record" structure at the end of the file. (This is equivalent to, but
much smaller than, the example zip file provided by the bug reporter.)
Bug: http://b/145925341
Test: treehugger
Change-Id: Iff64673bce7dae886ccbc9dd6c2bbe18de19f9d2
Not looking for other users right now, this is just enough to test
unzip/zip/zipinfo.
This includes tests for unzip and ziptool, along with a change to
unzip's behavior to fix AOSP `make dist` when using ziptool unzip.
Also add the boilerplate to run these tests on the device, in presubmit.
Fix command name in --help output.
Test: atest ziptool-tests
Change-Id: I5c0215a3ab8cb2cd5fc517ed9c188f81a7bf4520
Previously an unknown long option would cause a crash as we ran off the
end of the array.
Test: `ziptool unzip --unknown`
Change-Id: I7a7b6ac4a0fa157c111f936e837c20143cef9e28
The value of uncompressed may not be precisely representable when
implicitly casted to an IEEE 754 single precision float.
Assuming the code doesn't need a precise compression ratio, accept the
potential imprecision via explicit cast.
system/core/libziparchive/unzip.cpp:114:68: error: implicit conversion
from 'int64_t' (aka 'long') to 'float' may lose precision
[-Werror,-Wimplicit-int-float-conversion]
return static_cast<float>(100LL * (uncompressed - compressed)) / uncompressed;
~ ^~~~~~~~~~~~
Change-Id: If46cfa4eb2bb16a7491e52bb5d1c212ed5d59079
Bug: 139945549
Test: lunch hikey960-userdebug && mm
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Turns out the Mac doesn't have <error.h>. Add our own "die" function
instead, and use it everywhere so the Mac isn't using an untested
codepath.
One upside to this is that we'll now call ourselves "unzip" even when
run as `ziptool unzip ...`, which was awkward to fix with <error.h> but
trivial if we're rolling our own anyway.
Test: still works on Linux
Change-Id: I9cb1922595a21cd9f6d55a70d67e30090f8b7f21
But don't document it because it's a silly idea. Just call zipinfo
directly if you want zipinfo!
There are multiple uses of `unzip -Z` in the AOSP build, though, so we
may as well support it if people are already using it.
Test: manual
Change-Id: I04b05795badf63febe1210fbeaa96e3bd27237f1
golang doesn't include Unix mode by default.
Also show all the deflate variants ("defN" versus "defX").
Cope better with being called directly rather than via symlink.
Test: manual
Change-Id: I23b441c847ce9a557ea866b3c43bdf0542b26f10
Useful for debugging and hermetic builds. (Various places in the build
check to see that a file was stored uncompressed.)
Test: manual
Change-Id: I127e5689cd493ab06739b765beed50912dc9cc1d
Didn't find anything when I ran it, but it did get me to fix the
const/non-const void* in the API.
Test: treehugger
Change-Id: If3849d974965e3e5ffcbdaf5e47921316d717410
These add 16 bytes per ZIP entry, and are usually avoidable. APKs contain thousands of
deflated entries, so this overhead adds up to tens of kilobytes.
Bug: 135470635
Change-Id: Ib928aa41dd55cacc41f7394c218c4340d3bbd570
This would allow adding entries from one zip archive into
a new one without copying, directly from a ZipString object
Change-Id: I52f91008f497e798e044c43f57a6481cf4bec36d
All but one existing caller actually wants a std::string.
Bug: http://b/129068177
Test: treehugger
Change-Id: I428c4453edaae74451db56e9542e4e462f08d43a
Same issue as with FindEntry: using ZipString in the API forces all
callers to make sure they don't hit the ZipString length limits. Switch
to std::string_view and uniformly use the empty string as a way to
signal no prefix/suffix rather than nullptr.
Also use default arguments to make the common case of no prefix and no
suffix more convenient.
Also just use std::string to increase the lifetime of the provided
prefix/suffix rather than manual memory management.
Bug: http://b/129068177
Test: treehugger
Change-Id: I6675e39ce62fadd766386d77d27423013c17d6f7
Enable native bridge support for libbase, liblog,
libziparchive and libpropertyinfoparser.
This makes it possible to use them in binaries for translated
architectures.
Bug: http://b/77159578
Test: make
Change-Id: If67ce92288b17a052ea1e79a268e284f7d941439
Switch FindEntry and the ZipString constructor to std::string_view. This
lets us accept an over-long name so that we can reject it as too long.
Also fastboot changes to track the API change.
Bug: http://b/129068177
Test: treehugger
Change-Id: I7df7acd1fe2c46380b789c25f8909e0553e2d55e
Enable -Wconversion (but not -Wsign-conversion). Fix up code. Handle
some actual error cases:
* too many files
* files too large
Bug: 130039052
Test: atest ziparchive-tests
Change-Id: I632af317b9e65dbc728851efefd0d11a2b5c29b9
converting from a size_t to a uint8_t results in a loss of precision,
which triggers ubsan's implicit-unsigned-integer-truncation checker.
Make the conversion explicit.
This change allows the ziparchive-tests to pass with ubsan enabled.
Test: atest ziparchive-tests
Test: compiles and boots
Bug: 122975762
Change-Id: I63f28b58f1ca1f4c57323494cb1f4a41e0f34fba
Although ubsan's implicit-unsigned-integer-truncation sanitizer may be
happy, this code still performs an implicit conversion from a wider
width data structure to a narrower width data structure. Rather than
masking the bits, make the conversion explicit. This keeps ubsan happy
as well as addressing a -Wconversion warning.
This change addresses comments from the post-submit review
of a4e5433660.
Test: compiles and boots.
Bug: 122975762
Change-Id: I1fa6d6f8a6fcfb93ba9916b7d2b3564ca1d8caf3
std::hash returns a 64 bit value, which is truncated to a 32 bit value
in ComputeHash. ubsan's implicit-unsigned-integer-truncation doesn't
like this implicit truncation and crashes the program. Explicitly strip
off the top order bits after computing the hash.
Remove the windows specific version of the hash computation. The windows
compile now uses clang, so this code is obsolete. This also avoids us
having to add __attribute__((no_sanitize("integer"))) to the windows
code.
This is needed to support Android booting with ubsan's
implicit-unsigned-integer-truncation option enabled.
Test: compiles and boots
Bug: 122975762
Change-Id: I2f05fbf5ffee8e90a66a6fda32e80de9cca246c0
Update the powerof2 macro to one that is integer overflow safe.
This definition is the same one used by bionic, but cleaned up using
clang_format.
Unconditionally use this powerof2 macro, to ensure consistency across
all the build environments.
Test: compiles and boots
Change-Id: I21bfaf2360d1f77caf96365e20490b1deadfdfe0
The process of determining whether or not to emit a safetynet error
entry while processing a malformed file relies on addition overflow.
Since this is only logging, and logging which isn't used, delete the
code instead of trying to fix the logic which is causing the integer
overflow.
This change is necessary to enable integer sanitization on this code.
Somewhat related to Bug: 122975762
Test: atest ziparchive-tests
Change-Id: I6b41ccf7881348cb4e5236324eaa44a05662a725
Attempting to shift a uint8_t which has the top bit set results in a
value outside of the range allowable for a uint8_t. The process of
converting this value back to a uint8_t triggers ubsan's
implicit-conversion sanitizer.
Ensure the high order bit is stripped before shifting, so that the
shifted value fits into the allowable uint8_t range.
This change is necessary to enable integer sanitization on this code.
Somewhat related to Bug: 122975762
Test: atest ziparchive-tests
Change-Id: I940c8b2828ac88348d80f731274b990e35de6631
The code in libziparchive has lots of questionable looking but not
obviously wrong integer operations. In order to shake out integer bugs
in libziparchive (for example, commit
1ee4892e66 from bug 31251826) and provide
protection against security bugs, enable some integer sanitization
options in libziparchive.
Bug: 122975762
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=941802
Test: device boots and no obvious problems.
Change-Id: I215d81892a6eff12d692648c69a03e8200b334d7
Other CL in topic address the issue of the file pusher.
The explicit config for this module will not be required
anymore.
Test: atest -v ziparchive-tests
Bug: 124515549
Change-Id: I4dad8adbce0817009158bc191c2cce86c38d9e3e
To work around problems with the autogenerated one.
Bug: 117891984
Bug: 124515549
Test: atest ziparchive-tests
Change-Id: Ia4b352b7404255a4fe9e644a56ae9c5d41c79886
Prevent file descriptors from leaking across an exec() boundary.
Bug: 120983106
Test: compiles and boots
Change-Id: I392b0767674b557b1e4404a2ba63bc48e3e37b24
We can't add the ones that need a shared library because the
infrastructure doesn't work yet. (We also can't comment this in the file,
because there's no support for comments :-( .)
Bug: N/A
Test: N/A
Change-Id: I4d84f962bbf48fc708df336726c18e48fe206492
The Mac doesn't have lseek64, and this code is built with
_FILE_OFFSET_BITS=64 anyway.
Bug: N/A
Test: ran tests
Change-Id: Ibda49c44ecfbe21b304e163e48f7ea42d97e38a7
