CVE-2020-26159 is bogus; the "bug" was apparently a false positive
reported by Coverity, and the "fix" apparently wrong, see
<https://github.com/kkos/oniguruma/issues/221>.
libxml2 has no particular issues parsing HTML strings with NUL bytes;
these just cause truncation of the current text content, but parsing
continues generally. Since `::loadHTMLFile()` already supports NUL
bytes, `::loadHTML()` should as well.
Note that this is different from XML, which does not allow any NUL
bytes.
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 [Fri, 23 Oct 2020 08:30:07 +0000 (10:30 +0200)]
Make GC default threshold handling consistent
While the initial threshold is set to 10001 roots, the threshold
adjustment logic may then set it to 10000. The exact value really
doesn't matter, but we should make it consistent.
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.
Nikita Popov [Thu, 15 Oct 2020 14:42:59 +0000 (16:42 +0200)]
Simplify and fix generator tree management
This makes a number of related changes to the generator tree
management, that should hopefully make it easier to understand,
more robust and faster for the common linear-chain case. Fixes
https://bugs.php.net/bug.php?id=80240, which was the original
motivation here.
* Generators now only add a ref to their direct parent.
* Nodes only store their children, not their leafs, which avoids
any need for leaf updating. This means it's no longer possible
to fetch the child for a certain leaf, which is something we
only needed in one place (update_current). If multi-children
nodes are involved, this will require doing a walk in the other
direction (from leaf to root). It does not affect the common
case of single-child nodes.
* The root/leaf pointers are now seen as a pair. One leaf generator
can point to the current root. If a different leaf generator is
used, we'll move the root pointer over to that one. Again, this
is a cache to make the common linear chain case fast, trees may
need to scan up the parent link.
Nikita Popov [Wed, 21 Oct 2020 15:03:54 +0000 (17:03 +0200)]
Update bcmath.scale when calling bcscale()
We should keep the value of bcmath.scale and the internal
bc_precision global synchronized.
Probably more important than the ability to retrieve bcmath.scale
via ini_get(), this also makes sure that the set scale does not
leak into the next request, as it currently does.
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).
projects / php / log