Fix #80258: Windows Deduplication Enabled, randon permission errors
A recent bug fix regarding symlinks claimed:
> After resolving reparse points, the path still may be a reparse
> point; in that case we have to resolve that reparse point as well.
While that is basically correct, some reparse points may point to
inaccessible system folders (e.g. `IO_REPARSE_TAG_DEDUP` points to
"\System Volume Information"). Since we don't know details about
arbitrary reparse points, and are mainly interested in nested symlinks,
we take a step back, and only resolve `IO_REPARSE_TAG_SYMLINK` for now.
Fix #80280: ADD_EXTENSION_DEP() fails for ext/standard and ext/date
`ADD_EXTENSION_DEP()` relies on the `PHP_<extname>` config variables to
be set to `"yes"`, and since the standard and date extension are always
enabled, we define the respective variables uncoditionally.
Nikita Popov [Thu, 22 Oct 2020 14:04:22 +0000 (16:04 +0200)]
Don't crash on uninitialized tidy object
"Uninitialized" here means that the object was created ordinarily
-- no constructor skipping involved. Most tidy methods seem to
handle this fine, but these three need to be guarded.
Fix #80242: imap_mail_compose() segfaults for multipart with rfc822
libc-client expects `TYPEMESSAGE` with an explicit subtype of `RFC822`
to have a `nested.msg` (otherwise there will be a segfault during
free), but not to have any `contents.text.data` (this will leak
otherwise).
In libc-client 2007f `data` is declared as `unsigned char *`; there may
be variants which declare it as `void *`, but in any case picky
compilers may warn about a pointer type mismatch in the conditional
(and error with `-W-error`), so we're adding a `char *` cast for good
measure.
The original fix for that bug[1] broke the formerly working composition
of message/rfc822 messages, which results in a segfault when freeing
the message body now. While `imap_mail_compose()` does not really
support composition of meaningful message/rfc822 messages (although
libc-client appears to support that), some code may still use this to
compose partial messages, and using string manipulation to create the
final message.
The point is that libc-client expects `TYPEMESSAGE` with an explicit
subtype of `RFC822` to have a `nested.msg` (otherwise there will be a
segfault during free), but not to have any `contents.text.data` (this
will leak otherwise).
Nikita Popov [Tue, 20 Oct 2020 08:50:50 +0000 (10:50 +0200)]
Fix CCM tag length setting for old OpenSSL versions
While OpenSSL 1.1 allows unconditionally setting the CCM tag length
even for decryption, some older versions apparently do not. As such,
we do need to treat CCM and OCB separately after all.
Nikita Popov [Wed, 14 Oct 2020 11:03:03 +0000 (13:03 +0200)]
Fix bug #79983: Add support for OCB mode
OCB mode ciphers were already exposed to openssl_encrypt/decrypt,
but misbehaved, because they were not treated as AEAD ciphers.
From that perspective, OCB should be treated the same way as GCM.
In OpenSSL 1.1 the necessary controls were unified under
EVP_CTRL_AEAD_* (and OCB is only supported since OpenSSL 1.1).
Nikita Popov [Tue, 13 Oct 2020 14:46:32 +0000 (16:46 +0200)]
Allow passing $tag for non-authenticated encryption
openssl_encrypt() currently throws a warning if the $tag out
parameter is passed for a non-authenticated cipher. This violates
the principle that a function should behave the same if a parameter
is not passed, and if the default value is passed for the parameter.
I believe this warning should simply be dropped and the $tag be
populated with null, as is already the case. Otherwise, it is not
possible to use openssl_encrypt() in generic wrapper APIs, that are
compatible with both authenticated and non-authenticated encryption.
Fix #64076: imap_sort() does not return FALSE on failure
If unsupported `$search_criteria` are passed to `imap_sort()`, the
function returns an empty array, but there is also an error on the
libc-client error stack ("Unknown search criterion: UNSUPPORTED
(errflg=2)"). If, on the other hand, unsupported `$criteria` or
unsupported `$flags` are passed, the function returns `false`. We
solve this inconsistency by returning `false` for unsupported
`$search_criteria` as well.
Ignore memory leaks reported for some libc-client functions
At least on Windows, some static variables are lazily initialized
during `mail_open()` and `mail_lsub()`, which are reported as memory
leaks. We suppress these false positives.
intl: report more information about message pattern parse errors
The message patterns can be pretty complex, so reporting a generic
U_PARSE_ERROR without any additional information makes it needlessly
hard to fix erroneous patterns.
This commit makes use of the additional UParseError* parameter to
umsg_open to retrieve more details about the parse error to report that
to the user via intl_get_error_message()
Additional improve error reporting from the IntlMessage constructor.
Previously, all possible failures when calling IntlMessage::__construct()
would be masked away with a generic "Constructor failed" message.
This would include invalid patterns.
This commit makes sure that the underlying error that caused the
constructor failure is reported as part of the IntlException error
message.
Unless `topbod` is of `TYPEMULTIPART`, `mail_free_body()` does not free
the `nested.part`; while we could do this ourselves, instead we just
ignore additional bodies in this case, i.e. we don't attach them in the
first place.
Nikita Popov [Mon, 12 Oct 2020 09:03:39 +0000 (11:03 +0200)]
Deindirect source elements in zend_hash_merge
If the RHS has INDIRECT elements, we do not those to be added to
the LHS verbatim. As we're using UPDATE_INDIRECT, we might even
create a nested INDIRECT that way.
Fix #77040: tidyNode::isHtml() is completely broken
The documentation of `tidyNode::isHtml()` states that this method
"checks if a node is part of a HTML document". That is, of course,
nonsense, since a tidyNode is "an HTML node in an HTML file, as
detected by tidy."
What this method is actually supposed to do is to check whether a node
is an element (unless it is the root element). This has been broken by
commit d8eeb8e[1], which assumed that `enum TidyNodeType` would
represent flags of a bitmask, what it does not.
There is no such thing as the "end of the unix epoch", and if it was,
it would certainly not be 2037-10-11T02:00:00. There is, however,
potential integer overflow which we need to avoid.
projects / php / log