When a tar phar is created, `phar_open_from_fp()` is also called, but
since the file has just been created, none of the format checks can
succeed, so we continue to loop, but must not check again for the
format. Therefore, we bring back the old `test` variable.
Closes GH-9620.
The phar wrapper needs to uncompress the file; the uncompressed file
might be compressed, so the wrapper implementation loops. This raises
potential DOS issues regarding too deep or even infinite recursion (the
latter are called compressed file quines[1]). We avoid that by
introducing a recursion limit; we choose the somewhat arbitrary limit
`3`.
This issue has been reported by real_as3617 and gPayl0ad.
[1] <https://honno.dev/gzip-quine/>
It is insufficient to check whether the `base` is contained in `fname`;
we also need to ensure that `fname` is properly separated. And of
course, `fname` has to start with `base`.
Firstly, we must not forget to set appropriate error codes for "manual"
checks in `virtual_file_ex()`.
Secondly, we must not call `php_error_docref2()` for warnings regarding
unary functions; thus, we introduce `php_win32_docref1_from_error()`.
Closes GH-6872.
While "" is already treated the same way as absence, null is the
logically correct default here. Making this one argument non-nullable
is particularly pecular when considering that the preceding $alias
and $index arguments are both nullable.
When Phars are flushed, a new temporary file is created for each entry
which should be compressed, and the `compressed_filesize` is retrieved.
Afterwards, the Phar manifest is written, and only after that the files
are copied to the actual Phar. So for each such entry there is an open
temp file, what easily exceeds the limit.
Therefore, we use a single temporary file for all entries, and store
the start offset in the otherwise unused `header_offset` member. We
ensure that the `cfp` members are properly set to NULL even if flushing
fails, to avoid use after free scenarios.
This solution is based on a suggestion by @lserni[1].
Closes GH-6643.
[1] <https://github.com/box-project/box2/issues/80#issuecomment-77147371>
The default encoding of filenames in a ZIP archive is IBM Code Page
437. Phar, however, only supports UTF-8 filenames. Therefore we have
to mark filenames as being stored in UTF-8 by setting the general
purpose bit 11 (the language encoding flag).
The effect of not setting this bit for non ASCII filenames can be seen
in popular tools like 7-Zip and UnZip, but not when extracting the
archives via ext/phar (which is agnostic to the filename encoding), or
via ext/zip (which guesses the encoding). Thus we add a somewhat
brittle low-level test case.
Closes GH-6630.
When extracting compressed files from an uncompressed Phar, we must not
use the direct file pointer, but rather get an uncompressed file
pointer.
We also add a test to show that deflated and stored entries are
properly extracted.
This also fixes#79912, which appears to be a duplicate of #69279.
Co-authored-by: Anna Filina <afilina@gmail.com>
Closes GH-6599.
This fixes multiple issues:
* The first parameter may be resource|string.
* It's an overloaded signature. The second parameter cannot be
passed if the first one is a string. Use UNKNOWN default
value for that reason.
* Make parameter names in PharData::setStub() match those in
Phar.
Closes GH-6596.
We must not assume that the first end of central dir signature in a ZIP
archive actually designates the end of central directory record, since
the data in the archive may contain arbitrary byte patterns. Thus, we
better search from the end of the data, what is also slightly more
efficient.
There is, however, no way to detect the end of central directory
signature by searching from the end of the ZIP archive with absolute
certainty, since the signature could be part of the trailing comment.
To mitigate, we check that the comment length fits to the found
position, but that might still not be the correct position in rare
cases.
Closes GH-6507.
`phar_path_check()` already strips a leading slash, so we must not
attempt to strip the trailing slash from an now empty directory name.
Closes GH-6508.
Apparently, there are broken tarballs out there which are actually in
ustar format, but did not write the `ustar` marker. Since popular tar
tools like GNU tar and 7zip have no issues dealing with such tarballs,
Phar should also be more resilient.
Thus, when the first checksum check of a tarball in (presumed) in old-
style format fails, we check whether the checksum would be suitable for
ustar format; if so, we treat the tarball as being in ustar format.
Closes GH-6479.
Phar signatures practically are of limited size; for the MD5 and SHA
hashes the size is fixed (at most 64 bytes for SHA512); for OpenSSL
public keys there is no size limit in theory, but "64 KiB ought to be
good enough for anybody". So we check for that limit, to avoid fatal
errors due to out of memory conditions.
Since it is neither possible to have the signature compressed in the
ZIP archive, nor is it possible to manually add a signature via Phar,
we use ZipArchive to create a suitable archive for the test on the fly.
Closes GH-6474.
