Skip to content

Verify backup signature on self-update --rollback #12918

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Seldaek merged 1 commit into from
Jun 3, 2026
+289 −85
Merged

Verify backup signature on self-update --rollback #12918

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions doc/03-cli.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -809,6 +809,16 @@ sudo -H composer self-update
If Composer was not installed as a PHAR, this command is not available.
(This is sometimes the case when Composer was installed by an operating system package manager.)

Backups created for `--rollback` are stored in the [`data-dir`](06-config.md#data-dir),
and the public keys used to verify downloads are stored in `COMPOSER_HOME`. Both
directories must be writable only by the user that owns the Composer installation and
should be treated as trusted: a directory writable by other users could be used to plant
a malicious `composer.phar` that a privileged `self-update --rollback` would then install.
When rolling back to a tagged release the backup is verified against the published
signature from getcomposer.org before being installed (the rollback aborts on a mismatch
or if the signature cannot be downloaded); snapshot/dev builds cannot be verified this way,
so a rollback to one asks for confirmation when run interactively.

### Options

* **--rollback (-r):** Rollback to the last version you had installed.
Expand Down Expand Up @@ -1287,6 +1297,10 @@ Directory Specifications](https://specifications.freedesktop.org/basedir-spec/ba
it points to `$XDG_CONFIG_HOME/composer`. On other \*nix systems, it points to
`/home/<user>/.composer`.

This directory holds the public keys used to verify Composer downloads during
`self-update`, so it must be writable only by the user that owns the Composer
installation and should be treated as a trusted location.

#### COMPOSER_HOME/config.json

You may put a `config.json` file into the location which `COMPOSER_HOME` points
Expand Down
6 changes: 6 additions & 0 deletions doc/06-config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1048,6 +1048,12 @@ Specifications, and `$COMPOSER_HOME` on other unix systems. Right now it is only
used for storing past composer.phar files to be able to roll back to older
versions. See also [COMPOSER_HOME](03-cli.md#composer-home).

Because `self-update --rollback` restores a previously stored `composer.phar` from
this directory, it must be writable only by the user that owns the Composer
installation and should be treated as a trusted location. A directory writable by
other users would let them plant a malicious phar that a privileged rollback would
install.

## cache-dir

Defaults to `C:\Users\<user>\AppData\Local\Composer` on Windows,
Expand Down
Loading
Loading