PHIVE makes installation easy by providing a means to resolve the given alias to an actual download location, including the verification of the certificate supplied by the server. Once downloaded, the archive’s SHA1, SHA256 or SHA512 hash is verified as well as its OpenPGP/GnuPG signature.
Instead of re-downloading the same phar multiple times, the archive is kept at a shared location (by default in ~/.phive) and only a symbolic link is created for the project. You can of course also explicitly request a copy of the phar to be made in favor of symbolic links (use --copy).
Currently PHIVE supports three different methods to find the requested phar release:
GnuPG is the de facto standard for signing distribution packages and is also used to sign git commits and tags.
It is important that a cryptographically secure means exists to verify the integrity of release files as well as the authenticity of the signature provided. OpenPGP's design based on public and private keys as well as the free and open key server systems to share these public keys provide the optimal infrastructure towards this goal.
For the verification process to work (e.g. the gpg --verify ....), the public part of the private key used for signing must be known on the system doing the verification. That's why the public key has to get imported via it's ID (e.g. gpg --keyserver pool.sks-keyservers.net --recv-keys 0x9D8A98B29B2D5D79 for the signing key used by phar.io). Once the public key is in the so called keyring, signatures "linked" to that key can be verified. Otherwise it would be identical to openssl signatures (see below).
As long as the gpg private key is stored securely and privately, it's close to impossible that anybody else but the legitimate owner can create a signature that can be linked back to that very key. If an attacker uses a different private key, the verification will fail.
An attacker of course could create a new key pair claiming to be the original author. That's where the key ID and fingerprints come into play as those cannot be forged. Well, it probably could but that's what pretty much all cryptography is based on these days so it's probably reliable enough.
Long story short: Of course the phar and signature could be forged but the signer would not match up with the official signing key and thus the verification would fail. Phive warns if a signing key changed and asks the user to double check and confirm whether that is correct.
That leaves only one problem: On the first install of a phar theoretically a forged key could be used and phive wouldn't notice since there is no means to detect it yet. That's why upcoming versions of phive will have known/trusted IDs and public key data available for registered aliases.
For everybody else a manual verification of the finger print shown by phive must be performed. For instance by comparing it with the fingerprint published by the project. At Phar.io for examples we publish the fingerprint in the footer below to have an independent means of transport.
While OpenSSL signatures can be used to verify that a given file has not been altered once signed, they do not provide any identity information. Since the signer is not verifiable anybody could create a garbled phar with a matching pubkey file and there is no easy way to detect the difference from an official untampered distribution.
OpenSSL signatures as implemented in ext/phar do not provide a means to ensure the signer. For that to work, we'd need to have a CA-setup with certificates rather than just private and public keys. While that could of course be potentially interesting to implement, this is a whole different beast. And for now does not help our goal of secure installations and verifications.