danslo

Common subdirectories: ../244p8/./vendor/wikimedia/less.php/bin and ./vendor/wikimedia/less.php/bin
Common subdirectories: ../244p8/./vendor/wikimedia/less.php/lib and ./vendor/wikimedia/less.php/lib
Common subdirectories: ../244p8/./vendor/mtdowling/jmespath.php/bin and ./vendor/mtdowling/jmespath.php/bin
Common subdirectories: ../244p8/./vendor/mtdowling/jmespath.php/src and ./vendor/mtdowling/jmespath.php/src
--- ../244p8/./vendor/composer/autoload_psr4.php	2024-06-11 10:35:20.813889928 +0200
+++ ./vendor/composer/autoload_psr4.php	2024-06-11 10:35:28.822886888 +0200
@@ -48,7 +48,7 @@
     'ReCaptcha\\' => array($vendorDir . '/google/recaptcha/src/ReCaptcha'),
     'Ramsey\\Uuid\\' => array($vendorDir . '/ramsey/uuid/src'),
     'Ramsey\\Collection\\' => array($vendorDir . '/ramsey/collection/src'),

danslo

APSB23-50

https://helpx.adobe.com/security/products/magento/apsb23-50.html

Privilege Escalation

The vulnerability with the highest CVSS score of 8.8 (CVE-2023-38218) states that it is an unauthenticated privilege escalation due to improper input validation.

If we look at the diff we see a number of security related changes. One of those changes is the following in Magento\Customer\Plugin\Webapi\Controller\Rest\ValidateCustomerData::validateInputData:

danslo

#!/bin/sh

CURRENT_DIRECTORY=$PWD
OUTPUT_DIRECTORY=patches/graphql
MAGENTO_DIRECTORY=$1
FROM_VERSION=$2
TO_VERSION=$3

mkdir -p $OUTPUT_DIRECTORY

danslo

diff --git a/thrift/CMakeLists.txt b/thrift/CMakeLists.txt
index 8c46fd4..9e0eab8 100644
--- a/thrift/CMakeLists.txt
+++ b/thrift/CMakeLists.txt
@@ -60,6 +60,9 @@ list(REMOVE_ITEM files
 list(APPEND CXX_SOURCES ${files})

 add_definitions(-DNO_LIB_GFLAGS)
+if (APPLE)
+  add_definitions(-DTHRIFT_MUTEX_EMULATE_PTHREAD_TIMEDLOCK)

danslo

diff --git a/hphp/util/generate-buildinfo.sh b/hphp/util/generate-buildinfo.sh
index b3365e0..77195f3 100755
--- a/hphp/util/generate-buildinfo.sh
+++ b/hphp/util/generate-buildinfo.sh
@@ -79,7 +79,7 @@ fi
 if [ x"$HHVM_REPO_SCHEMA" = x"" ] ; then
   HHVM_REPO_SCHEMA=$(sh -c "$find_files" | \
       grep -v '^hphp/\(benchmarks\|bin\|hack\|hphp\|neo\|public_tld\|test\|tools\|util\|vixl\|zend\)' | \
-      xargs -d '\n' cat | sha1sum | cut -b-40)
+      xargs -d '\n' cat | shasum -a 1 | cut -b-40)

danslo

require 'formula'

class Binutilsfb < Formula
  homepage 'http://www.gnu.org/software/binutils/binutils.html'
  url 'http://ftpmirror.gnu.org/binutils/binutils-2.24.tar.gz'
  mirror 'http://ftp.gnu.org/gnu/binutils/binutils-2.24.tar.gz'
  sha1 '1b2bc33003f4997d38fadaa276c1f0321329ec56'
  revision 1

  keg_only "We're just a patched version."

danslo

diff --git hphp/runtime/base/runtime-option.cpp hphp/runtime/base/runtime-option.cpp
index 96c143c..43748b0 100644
--- hphp/runtime/base/runtime-option.cpp
+++ hphp/runtime/base/runtime-option.cpp
@@ -333,6 +333,7 @@ bool RuntimeOption::EnableObjDestructCall = true;
 bool RuntimeOption::EnableEmitSwitch = true;
 bool RuntimeOption::EnableEmitterStats = true;
 bool RuntimeOption::CheckSymLink = true;
+bool RuntimeOption::StrictSignaling = false;
 int RuntimeOption::MaxUserFunctionId = (2 * 65536);

danslo

Zeev Suraski (Zend CTO) recently released some benchmarking figures comparing HHVM to PHPNG (and PHP 5.6). I was particularly interested in the results for SugarCRM. They show a 14-28% speed benefit in favor of PHPNG. I decided to investigate, and ran some basic benchmarks with siege.

It came up with the following results:

	Trans/sec
PHPNG	24.12
HHVM	20.74
Diff.	16.29%

danslo

HHVM:
** SIEGE 3.0.5
** Preparing 200 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:		        8248 hits
Availability:		      100.00 %
Elapsed time:		       59.28 secs
Data transferred:	       45.00 MB

danslo

==20393== 8 bytes in 1 blocks are definitely lost in loss record 88 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 89 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 90 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 91 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 92 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 93 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 94 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 95 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 96 of 1,153
==20393== 8 bytes in 1 blocks are definitely lost in loss record 97 of 1,153