The docs contain several how-tos about gpg and signatures and such. I suggest to add one more page or paragraph to explain the following argument:
- package developers who publish a phar should sign the phar so that the integrity and origin can be validated
- they should also document the key they used for this as a king of "trust anchor" somewhere in their website/docs
I have recently proposed this to several projects
It seems to me that some people are not aware of the benefit of a "trust anchor" in the form of a clearly documented key ID that is used to sign the phars. This is especially important if downstream consumers want to install tools in CI or some non interactive build environment where we want to use --trust-gpg-keys so we want to know the key id up front.
The docs contain several how-tos about gpg and signatures and such. I suggest to add one more page or paragraph to explain the following argument:
I have recently proposed this to several projects
It seems to me that some people are not aware of the benefit of a "trust anchor" in the form of a clearly documented key ID that is used to sign the phars. This is especially important if downstream consumers want to install tools in CI or some non interactive build environment where we want to use
--trust-gpg-keysso we want to know the key id up front.