Skip to content

chore(release): prepare v4.13.2 - #1948

Open
mrrobot47 wants to merge 3 commits into
EasyEngine:developfrom
mrrobot47:release/v4.13.2
Open

mrrobot47 wants to merge 3 commits into
EasyEngine:developfrom
mrrobot47:release/v4.13.2

Conversation

@mrrobot47

Copy link
Copy Markdown
Member

Summary

Upgrade notes

  • site-type-wp/php v1.12.1 call validate_site_name(), added in site-command v3.8.2, so the three pins ship together.
  • New upgrade migrations: each site's database user is restricted to its own database, existing self-signed roots are repaired as a real CA with the same key, and backup metadata loses stored site passwords (site-command); admin-tools sites stop mounting the EasyEngine database (admin-tools-command); existing logs are restricted to root and have earlier secrets masked (core).
  • Admin-tools sites have their php and nginx containers recreated during the update, so expect a few seconds of 502 on those sites.
  • After the update an older ee refuses non-cli commands, so clone and sync over ssh need v4.13.2 on both hosts.

After merge

  • Merge develop into master and push the signed v4.13.2 tag. CI then builds the phar, publishes it to easyengine-builds and creates the draft release, which gets reviewed before publishing.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Bundled database-permission, certificate, and container migrations require human validation of existing-site upgrades before release.

0 open findings

What changed in this PR

Prepares EasyEngine v4.13.2 with bundled security and bug fixes on the PHP 7.4-compatible release line.

Changes:

  • Bumps the release version from 4.13.1 to 4.13.2.
  • Updates seven bundled packages, keeping the interdependent site packages aligned.
  • Leaves other package pins and container image versions unchanged.
File Description
VERSION Sets the release version to 4.13.2.
composer.lock Locks seven updated packages and refreshes the content hash.
composer.json Pins the seven packages to their new patch releases.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@Arittra-Bag

Arittra-Bag commented Oct 14, 2026 •

Copy link
Copy Markdown

Tested the 4.13.2 candidate on a server, using PR head a7a7ee59357b94d04e1d662f3f1a65e1f743f48c and its locked production dependencies. The PHAR was built with the repository's build script and installed over 4.13.1 after retaining the original binary and state snapshots. No EasyEngine source changes were made.

The live environment used Ubuntu 26.04.1, PHP 8.5.4 and Docker 29.9.0. This validation exercised the supplied release changes. Real server operations and controlled supplemental checks are distinguished below.

The executed checks for the 23 release PRs produced the expected results, and no newly introduced regression was identified in the tested release scope. Two observations associated with the 4.13.1 baseline are recorded separately below. The coverage limits remain explicit; these results do not imply that every possible deployment or failure branch was exercised.

Passing live checks for the 4.13.2 release changes

Release PRs Checks and results
site-command #509, site-type-php #117, site-type-php #118, site-type-wp #243, site-type-wp #244, easyengine #1943 Created HTML, PHP with a database, and WordPress sites through actual background provisioning. All became live, returned HTTP 200, and completed explicit metadata refreshes successfully. Server metadata reports 4.13.2. Ten invalid hostname cases were refused without creating sites. Quotes, dollar signs, backticks and backslashes were preserved in supplied PHP/WordPress credentials. PHP queried a reachable controlled database, WordPress authenticated its administrator, and its runtime database password matched the stored value. The title matched after normal HTML entity decoding. Weak WordPress passwords were refused without echoing the supplied value.
site-command #501, site-command #510, site-command #511, easyengine #1947 Local WordPress cloning, file/upload/database sync, cache-enabled cloning and noninteractive cache cleaning succeeded. Both clone directions also succeeded through real SSH loopback. The four clone fixtures passed database checks and returned HTTP 200. Site URLs were rewritten. Existing destinations retained their marker files, and same-site/disabled-source requests were refused. Generated clone credentials were absent from the new CLI log. HTML/PHP clone requests retained the existing WordPress-only guard. Noisy SSH listing output was refused rather than interpreted as an empty host.
site-command #512 Before/after database grant snapshots showed eight legacy grant rows changed to escaped exact patterns. A migrated test user could access its own database and was denied access to a lookalike database. The dedicated pre-upgrade PHP fixture already had an exact grant, so an initial expectation that this particular row must change was corrected.
site-command #513 The existing self-signed root was repaired to CA:TRUE while retaining its public key. An existing leaf certificate still verified against the repaired root.
site-command #514, config-command #14, easyengine #1944 Private JSON/config output retained its expected values. Secret and nonsensitive config values were not persisted as INFO output. Leading-dash config values worked. Historical logs contained no matches for 21 known pre-upgrade credential values after migration. CLI log directories/files had 0700/0600 permissions, and an unprivileged account could not read the CLI log.
site-command #515 Real PHP backup and restore to a verified local-only storage destination succeeded, restoring both file and database markers. Fresh local/stored backup metadata omitted the database, root database, application administrator and site authentication password fields. Migration scrubbed both supported local metadata layouts while preserving other values and modes, and left invalid JSON and symlink fixtures untouched. With generated credentials, WordPress backup and restore succeeded, retained model credentials and produced metadata without those password fields. The wp-content file marker was restored and its database remained functional after restoration. Previously uploaded remote metadata was not scrubbed.
site-command #516, site-command #517 Real HTTP-01 certificate issuance succeeded under umask 077, with apex/www SANs, trusted HTTPS and the expected redirect. Two subsequent SSL off/on cycles succeeded. Their www probes used different nonce paths, 33.5 seconds apart, and left no probe markers behind. Reapplying an already-enabled SSL setting retained its expected refusal.
admin-tools-command #54, auth-command #60 The legacy database host mount was removed from the tested admin-tools containers, including a disabled site's configuration. That site remained disabled. Enable/disable and mailhog toggles worked. Twelve external HTTP assertions verified unauthenticated rejection, authenticated access, global credential creation/update/deletion and independent admin-tools protection. Duplicate credential creation was refused without changing the existing record.
log-command #8 A real log follower announced the regular file and read its known line. It skipped an outside symlink and FIFO. A filename containing shell metacharacters caused no command execution. Invalid line-count arguments were refused.
easyengine #1945 Eight live remote-flag placement/strict-mode checks refused unsupported --ssh/--http targeting and preserved the target. The pre-migration check also left the database unchanged.
easyengine #1946 The deployed PHAR contained the expected seven locked package versions/references and excluded the targeted EasyEngine package test/feature trees. Package source content was compared with the locked source.

Supplemental exact-candidate checks

These exercised packaged code with controlled inputs or intercepted external command sinks, rather than claiming additional live infrastructure coverage:

  • 152 site-component assertions passed on each of PHP 7.4 and 8.5, covering strict site-list parsing, noisy/nonzero remote results, destination-preserving rollback races, validation boundaries, quoting and clone/SSL control flow.
  • Eleven direct PHP remote-verifier assertions passed on each runtime, covering quoting, failure handling and cleanup. The ordinary-create behavior is recorded separately under the 4.13.1 baseline observations.
  • Core checks passed: 28 masking/output-shape assertions, 29 process/remote-target assertions, 33 historical-log migration assertions and 17 Docker argument assertions. Migration checks included text/rotated/gzip logs, modes and original-file preservation on a controlled copy-open failure.
  • 1,405 PHP syntax checks passed on PHP 8.5, and 203 targeted candidate-code syntax checks passed on PHP 7.4. The PR's Behat checks were also successful for PHP 7.4 and 8.0–8.5 when checked. Those CI results are additional evidence, separate from the locked PHAR deployed here.

Existing 4.13.1 baseline observations, separate from the release checks

The following observations are retained for completeness and separate follow-up. They were assessed against the original 4.13.1 implementation and were not identified as newly introduced regressions from the 23 release PRs:

  • PHP external database credentials: ordinary PHP creation accepted incorrect external database credentials. Comparison with the original 4.13.1 implementation showed that the external verifier is not reached by that creation path. The quoting changes in site-type-php Any option to use SPDY? #117/Improve the EE security with adding Fail2Ban #118 passed their exercised checks. Invalid-credential rejection by ordinary creation remains a separate existing behavior, and is not reported as a passing test.
  • WordPress backup with shell-character database passwords: backup failed for the special-password fixture, although creation and runtime authentication succeeded. The database backup routine, including its unquoted password argument construction, is identical in the original 4.13.1 PHAR and the tested candidate. This is separate from the metadata changes validated for site-command Install php5-memcached? #515. The generated-credential WordPress backup/restore control and the PHP backup/restore control passed. No change to this existing backup behavior was made during validation.

Test conditions and coverage limits

  • Database checks used --skip-ssl to match this server's database/client configuration. The default client invocation requested SSL from a server that does not provide it.
  • SSH positives used one server with loopback transport, not an independent second or empty remote host. Empty-host, parser and rollback branches received controlled supplemental coverage. Not every SSL repair/failure branch, private database topology, cloud backup provider or filesystem failure mode was exercised live. Cache cleaning succeeded, but stale-cache invalidation was not independently demonstrated with prewarmed content.
  • The candidate was installed directly. Published stable-channel update delivery was not exercised before release.

All thirteen disposable server sites were removed after testing. The three background archive jobs and their provisioning plays completed successfully. The original nine site records and authentication records were preserved. All nine original endpoints returned the baseline status with their existing HTTPS redirects followed using local resolution; this was an endpoint check, not a comparison of full response bodies or TLS trust for every original site. Temporary test database/user, metadata/log fixtures, SSH authorization and additional swap were removed. Temporary local notification suppression was restored. The server remains healthy on 4.13.2, with rollback material retained privately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants