David, I appreciate your concern regarding supply chain security. While there is still a lot of work to do, there are some steps we have taken at MongoDB to help users protect themselves.
Just to clarify some naming confusion, the PHP driver for MongoDB consists of two parts, the mongodb extension (typically installed via PECL, in your case through Archlinux) and the library, which is typically installed using composer using metadata hosted on packagist.org.
When looking at supply chain security, we have to treat the extension and library separately due to the two completely different installation mechanisms. What both have in common is that GitHub is the canonical source for all releases. This is because as part of our secure software development lifecycle program at MongoDB, we have taken several steps to protect the integrity of the code:
- Code can not be pushed to branches directly, but have to be reviewed in a pull request to be mergeable
- Releases can only be done through an automation with credentials that are not accessible to MongoDB employees
- Tags on GitHub are signed using a PGP key
- For the extension, we provide a PECL archive along with a signature for each release
After a release, we upload this PECL archive to https://pecl.php.net/mongodb so that it becomes installable using the pecl binary. Packages provided by Linux distributions are not within our control, and you have to trust the packager to not compromise the integrity of the package.
An alternative is manually fetching the file from a GitHub release and verifying it against the signature we attach to that same release. We have documented these steps in the Release Integrity section of the README. We also plan to add GitHub attestation to the release process to give more options for verifying release integrity.
When it comes to the library, the difference to the driver is that we don’t provide a separate archive with a generated signature, as we completely rely on composer to install our packages. Composer metadata is automatically updated through GitHub, and when downloading code through composer by default the archive of the corresponding tag is downloaded. In this case, you’re trusting GitHub to serve up the correct code for a tag. Note that there are no integrity checks added here, as the archives provided by GitHub are generated dynamically and thus do not have the same signature over time.
This brings us to the new pie installer for extensions. This builds on the packagist.org ecosystem, so everything works the same as for composer packages. The only difference is that we instruct pie to download the archive attached to a release as opposed to fetching the archive automatically generated by GitHub. The main reason for this is technical, but it comes with the benefit of potentially adding signature verification in the future.
I hope this gives you a bit more background on how we try to preserve release integrity and keep your supply chain secure, but please follow up if you have any more questions.