Impact
When a user runs pie self-update, the gh-CLI verification path runs:
gh attestation verify --owner=php <downloaded.phar>
(src/SelfManage/Verify/GithubCliAttestationVerification.php:48-54.)
--owner=php scopes the lookup to the GitHub php organisation. It does
not pin the source repository. Any Sigstore attestation produced by any
repo under the php org will satisfy the gate, regardless of whether the
artefact actually came from php/pie.
The OpenSSL fallback verifier already pins
SOURCE_REPOSITORY_URI = https://github.com/php/pie
(FallbackVerificationUsingOpenSsl.php:22-26), so the two paths disagree
on strictness, and VerifyPieReleaseUsingAttestation::verify runs the
looser one first (VerifyPieReleaseUsingAttestation.php:32-45).
Fix
Add --repo=php/pie to the verification command at
src/SelfManage/Verify/GithubCliAttestationVerification.php:48-54:
$verificationCommand = [
$gh,
self::GH_ATTESTATION_COMMAND,
'verify',
- '--owner=php',
+ '--repo=php/pie',
$pharFilename->filePath,
];
Impact
When a user runs
pie self-update, the gh-CLI verification path runs:(
src/SelfManage/Verify/GithubCliAttestationVerification.php:48-54.)--owner=phpscopes the lookup to the GitHubphporganisation. It doesnot pin the source repository. Any Sigstore attestation produced by any
repo under the
phporg will satisfy the gate, regardless of whether theartefact actually came from
php/pie.The OpenSSL fallback verifier already pins
SOURCE_REPOSITORY_URI = https://github.com/php/pie(
FallbackVerificationUsingOpenSsl.php:22-26), so the two paths disagreeon strictness, and
VerifyPieReleaseUsingAttestation::verifyruns thelooser one first (
VerifyPieReleaseUsingAttestation.php:32-45).Fix
Add
--repo=php/pieto the verification command atsrc/SelfManage/Verify/GithubCliAttestationVerification.php:48-54:$verificationCommand = [ $gh, self::GH_ATTESTATION_COMMAND, 'verify', - '--owner=php', + '--repo=php/pie', $pharFilename->filePath, ];