Security updates and disclosure #

This page is for the security lead and the system administrators of a host who keep many Exponential sites up to date, and for support staff who receive a report about a possible vulnerability. It says which versions are supported, how a fix reaches a site, and how to report a problem. The policy itself is the repository's SECURITY.md; the update routine is 13.15 Keeping up to date.

Contents #

1. Supported versions
2. How fixes are published
3. Following releases
4. Rolling updates out
5. Checking files after an update
6. Everything else that needs updates
7. Reporting a vulnerability
8. Telling customers
9. Checklist

Supported versions #

From SECURITY.md:

Security fixes are made on main and published with the next 6.0.x release. Sites on older lines, including those that still run the product its creator discontinued after almost 18 years, get no fixes; plan their migration (Migrating customers: overview).

How fixes are published #

A published tag is never changed. A fix for a problem in an earlier tag reaches you as the next release, not as a corrected copy of the old one. Releases are immutable tags on Packagist and GitHub, with changelogs. For a host this means:

• the version number a site reports is reliable: the same version is the same code everywhere;
• "is this site patched?" is answered by comparing its version with the release that fixed the problem;
• every extension is its own Composer package with its own releases; follow those too.

Following releases #

composer outdated                 # what is newer than the locked versions
composer audit                    # known vulnerabilities in the locked dependencies
composer show se7enxweb/exponential   # the version a site runs

Run these per installation from a central job and collect the results, or use the Setup > Updates and packages screen of the ezupdate extension, whose check for updates changes nothing (ezupdate, Automated updates with ezupdate). Keep composer.lock in each site's version control so the result is the same on every machine.

Rolling updates out #

1. Read the changelog and the upgrade notes of the release (Upgrading, Chapter 11).
2. Update a copy first (a staging copy of the customer's site, or a representative test site).
3. Then the live site: composer update <package>, the database updates the release names, then php bin/php/console exp:velocity deploy (or autoloads, cache clear and a PHP-FPM reload by hand).
4. Check file consistency (below).
5. Smoke test the front page and the administration sign-in.

For many sites at once: Upgrading customer sites and Deploying changes. Use maintenance mode where the update needs database changes.

Checking files after an update #

Setup > Upgrade check compares every file with the release's share/filelist.md5 ("Check file consistency") and the schema with the release's ("Check database consistency"). Both only read. The same from a shell, without a database:

php bin/php/checkmanifest.php --all                 # exit 0 when nothing is modified or missing
php bin/php/checkmanifest.php --all --extensions    # also extensions with their own manifest

A modified kernel file nobody changed deserves a look; see Compromised site (The upgrade check).

Everything else that needs updates #

• PHP, the database server and the operating system.
• Velocity's engine (its releases fix security issues too), then exp:velocity deploy.
• FrankenPHP's binary: version and checksums are pinned in [FrankenPHPSettings] Version and Sha256[]; change them together.
• The customer's own extensions: review them for the patterns fixed in the kernel (SQL built from request data, shell commands without escapeshellarg(), output without escaping), and regenerate extensions made by the RAD wizards before their fix (RAD tools: security, 6.0.13 hardening notes).
• request-shield, when installed, as its own package.

Reporting a vulnerability #

Report security issues privately, never in a public issue tracker or discussion:

• by mail to [email protected], or
• as a private advisory on GitHub: https://github.com/se7enxweb/exponential/security/advisories/new.

SECURITY.md says a first answer can be expected within one business day. Include:

• the version (composer show se7enxweb/exponential, or the tag or commit) and the PHP version;
• the engine that serves the site (Velocity, FrankenPHP, Apache or nginx with PHP-FPM) and the database;
• what an attacker can do, and the steps to reproduce it.

Leave out passwords, secrets and personal data, including those of the customer whose site showed the problem. The reporter is told whether the report is accepted and kept informed while a fix is prepared; an accepted issue is fixed on main and released with the next 6.0.x version. Problems in a third-party extension go to that extension's maintainers; the help's report page explains the trackers.

Telling customers #

When a release fixes a security problem, a host may choose to:

• inform affected customers which sites were updated and when;
• for sites that cannot be updated at once, document the gap with a date to close it, as the Security review checklist asks;
• never publish details of an unfixed problem before the project has released the fix.

Checklist #

• To do: Every site on the newest 6.0.x, or the gap documented with a date.
• To do: composer outdated and composer audit run regularly for every installation; composer.lock in version control.
• To do: Updates tested on a copy first; file consistency checked after every update.
• To do: PHP, database server, operating system, Velocity's engine and extensions included in the routine.
• To do: A named owner who reads release notes and receives security mail.
• To do: Support staff know the private reporting route and never use a public tracker for security reports.

Related pages #

• Security for hosts: overview
• SECURITY.md
• Security hardening: Reporting a vulnerability
• Working with the project and 7x
• Upgrading customer sites
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.