PHP, which stands for "PHP: Hypertext Preprocessor" is a widely-used Open
Source general-purpose scripting language that is especially suited for
Web development and can be embedded into HTML. Its syntax draws upon C,
Java, and Perl, and is easy to learn. The main goal of the language is to
allow web developers to write dynamically generated webpages quickly, but
you can do much more with PHP.
===> The following configuration options are available for php84-8.4.27_2:
CGI=on: Build CGI version
CLI=on: Build CLI version
DEBUG=off: Build with debugging support
DTRACE=on: Build with DTrace probes
EMBED=on: Build embedded library
FPM=on: Build FPM version
IPV6=on: IPv6 protocol support
LINKTHR=on: Link thread lib (for threaded extensions)
MYSQLND=on: Build with MySQL Native Driver
NOASLR=off: Disable ASLR support
PCRE=on: Use system pcre instead of bundled one
PHPDBG=off: Interactive PHP debugger
ZTS=off: Force Zend Thread Safety (ZTS) build
===> Use 'make config' to modify these settings
SECURITY: session upload progress (CVE-2026-115560, informational)
php.ini-production and php.ini-development now ship with
session.upload_progress.enabled = 0 as a temporary mitigation until the
next regular PHP bugfix release. It only takes effect if you copy one of
these templates to /usr/local/etc/php.ini. Without a php.ini, the
compiled-in default (enabled) applies.
Applications that read $_SESSION["upload_progress_*"] (upload progress
bars) will stop receiving progress data while this is off.
If upgrading
SECURITY: session upload progress (CVE-2026-115560, informational)
Until the next regular PHP bugfix release, session.upload_progress.enabled
should be 0. The shipped php.ini-production and php.ini-development now
set it, but existing php.ini files are never modified on upgrade, and
with no php.ini the compiled-in default (enabled) applies. If you
already applied this setting for CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp),
keep it; nothing further is needed.
The issue needs an unusual combination: session.serialize_handler set
to php_binary or php_serialize in configuration, switched to php at
runtime with ini_set() before session_start(), with upload progress
still enabled. Applications that never change the handler at runtime
can keep the feature enabled.
Check the effective value per SAPI (CLI and FPM/mod_php may load
different ini files):
php -r 'var_dump(ini_get("session.upload_progress.enabled"));'
For FPM/mod_php, use phpinfo() from a web request. Ini files are read
from /usr/local/etc/php.ini and /usr/local/etc/php/*.ini.
Check both halves of the precondition:
php -r 'var_dump(ini_get("session.serialize_handler"));'
grep -rn serialize_handler /usr/local/www /usr/local/etc/php* \
/usr/local/etc/apache2*
A match on one half alone is not vulnerable; the combination is. To
make runtime switching impossible in FPM, set in the pool config:
php_admin_value[session.serialize_handler] = php
This breaks applications that legitimately need php_serialize at runtime.
After changing any setting, restart the PHP service, e.g.:
service php_fpm restart
This notice will be removed once the fixed release is in the tree.
Reason:
The default version of PHP has been switched from 8.4 to 8.5.
If you use binary packages you should make a list of php packages
before running 'pkg upgrade':
# pkg info \*php84\* > ~/installed-php-ports-list
After the upgrade, check with such list if all your php extensions
are still installed, and reinstall them if needed.
If you use mod_php84 you need to deinstall it and install mod_php85.
lang/php84: Disable session upload progress in shipped php.ini templates
Set session.upload_progress.enabled = 0 in php.ini-production and
php.ini-development as a temporary mitigation for CVE-2026-115560, until
the next regular upstream bugfix release. The issue requires an
application to set session.serialize_handler to php_binary or
php_serialize and switch it to php at runtime via ini_set() before
session_start(), with upload progress still enabled.
The templates only affect new installs and users who copy them to
php.ini; existing php.ini files are untouched. Add a pkg-message
describing the change and how to check the effective configuration.
Security: CVE-2026-115560
lang/php8*: Force fresh FreeBSD.org package builds.
No functional changes to the ports.
The packages were built manually today from a temporary branch to
incorporate the RCE fixes without triggering unnecessary rebuilds.
These fixes were cherry-picked onto the previous package build rather
than built from a published branch. The cherry-picks also omitted the
lmdb change in 85ba298b7e0.
Bump the ports to trigger fresh builds from the published tree,
ensuring reproducibility and accurate package metadata.
MFH: 2026Q4
databases/lmdb: allow to install both 0.x and 1.x together
LMDB 1.0 and the legacy 0.9 ABI cannot be mixed, the datanase format are
incompatibles as well.
Rename or relocate everything databases/lmdb0 installs so that it no
longer overlaps with databases/lmdb:
- the utilities are now mdb_copy0, mdb_dump0, mdb_load0 and mdb_stat0
- the header is include/lmdb0/lmdb.h
- the linker name is liblmdb0.so, the shared object keeps its ABI name
liblmdb.so.0 so already linked programs are unaffected
- the pkg-config file is lmdb0.pc
A compatibility prefix holding the previous layout is also installed
under ${PREFIX}/lmdb0/ (include/, lib/ and libdata/pkgconfig/) so that
build systems which expect to find lmdb.h and -llmdb relative to a
single directory only need a path change.
Now all ports should migrate to lmdb 1.X and use the lmdb 0.9 port to ease
in the migration path, lmdb, the lmdb 0.x is supposed to get removed at
some point.
Approved by: mat (portmgr)
Reviewed by: mat
Differential Revision: https://reviews.freebsd.org/D60741
databases/lmdb0: Add port for LMDB 0.9.x legacy ABI
LMDB 1.0 introduced an incompatible on-disk format change and subtle
API breakage: applications that compiled cleanly against 1.0 headers
could fail silently at run time. Known affected ports include dns/knot3,
mail/bogofilter, and mail/postfix; the postfix issue has been confirmed
upstream. Linux distributions such as Arch Linux have observed the same
breakage. Samba can also be affected in certain configurations.
Because the regression is not detectable in an -exp build run -- the
postfix failure only manifests at run time, and bogofilter was caught
only because post-build self-tests happen to exercise this path -- we
cannot rely on package builds to validate the 1.0 upgrade.
This commit introduces databases/lmdb0 as a holding port for the 0.9.35
(Only the first 15 lines of the commit message are shown above )
lang/php84: Update version 8.4.20=>8.4.21
- Optionize JIT. JIT for opcache has been disabled by default. Make it
and option to conditionally depend on capstone [1]
Changelog: https://www.php.net/ChangeLog-8.php#8.4.21
PR: 294233 [1]
Reported by: chris@chrullrich.net [1]
MFH: 2026Q2
all: drop support for FreeBSD 13, mips and risc64sf
Reviewed by: many (*)
Differential Revision: https://reviews.freebsd.org/D55624
Differential Revision: https://reviews.freebsd.org/D55642 (merged in from bofh)
many (*)
acm arrowd brooks cmt dch decke dinoex eduardo fluffy fuz gahr garga
jbeich joerg jrm kai kenrap martymac matthew mfechner michaelo mizhka
nobutaka pkubaj se tagattie thj
Anton Saietskii
GenericRikka
Gert Doering
Jan Bramkamp
Oleh Hushchenkov
Oleksandr Kryvulia
Ralf van der Enden
Yamagi
desktop kde python tcltk office
lang/php84: fix build with LibreSSL
sk_X509_new_reserve does not exist in LibreSSL, only OpenSSL.
Obtained from: OpenBSD ports
Approved by: bofh (maintainer)
Differential Revision: https://reviews.freebsd.org/D55921
lang/php84: use bundled argon only on base win OpenSSL 3.5+
OpenSSL 3.5 introduced in base at 1500059
MFH: 2026Q1
Approved by: portbgr blanket (fix build)
lang/php84: Correct php_fpm in rc.d script
Correct a reference in the php_fpm.in file, changing php-fpm to php_fpm to
ensure consistent naming when invoking the rc.d script for PHP-FPM profiles.
PR: 285584
www/php84-opcache: fix build on non-amd64 / non-i386
post-configure step unconditionally tried to use JIT source, even when JIT was
disabled in ports (on aarch64) or in the source (powerpc*, riscv*, armv7),
which caused build breakage.
This commit checks whether JIT is supported (currently it is only on aarch64,
amd64 and i386) and only then uses JIT sources.
It also enables JIT on aarch64, which was disabled previously.
