Every commit and release to the Apex network is automatically digitally signed using x.509 certificates. Any commits made to Apex code repositories without a valid digital signature are automatically rejected, and release signatures are verified before Apex will install any package or upgrade on your local machine, This helps ensure no malicious actors injected code into a repository, and helps keep your system secure.

How it Works

During account registration / your first commit, the CLI based registration wizard will generate a 4096 bit RSA key and corresponding CSR, which is then signed by the Apex network during registration. This provides you with a proper x.509 certificate, signed by the Apex network trustable by verifying it against the Apex root certificate.

For every commit made, Apex will generate a merkle root using the SHA1 hashes of all files within your package and the previous merkle root if one is available. The merkle root generated is a SHA256 hash, which is then signed using the RSA key that was generated during registration. The signature, merkle root and inventory are included with each commit, and the Apex network will automatically reject any commits without a valid signature. This provides you with assurance that no outside party can inject code into your repositories as if a valid merkle root with corresponding digital signature generated using your private key isn't provided, the network will reject the commit.

This entire process is made as seamless as possible. Registration during your first commit will take a couple minutes to generate your signing certificate, but it's a one-time process, and that's it. From there, you simply commit as you would with any version control system, and at most you'll be asked for the password to your private key if you defined one during registration. Nothing more, and the entire signing process is seamless and transparent.

Package Verification

When a user installs a package, the digital signature is automatically verified before Apex allows the install to happen. The package is initially downloaded into the system's temporary directory, and a merkle root using the SHA1 hash of all files is generated.

The merkle root is compared against the one assigned to the release, plus the signature is checked to be that of the merkle root and signed by the author's signing certificate. The chain of trust up to the root Apex certificate is also verified, and any certificates not already on the local machine are retrived from the public ledger's API at https://ledger.apexpl.io/. Lastly, the fingerprint of each certificate is sent to the public ledger's API to check for any revocations.

Composer Packages

Although you can rest assured that all code within any installed Apex packages is secure from code injection, that's unfortunately not the case with all Composer packages installed within the /vendor/ directory. To help combat this insecurity, the Apex Signer has been developed which allows package authors to effortlessly include digital signatures for all releases of their packages.

To verify any installed Composer packages that utilize digital signatures, within your Apex installation directory simply run the command:

    vendor/bin/signer

This will go through all installed Composer packages and look for a signatures.json file in each. When found, it will generate a merkle root of the SHA1 shahes of all files of that package, then compare it to both, the merkle root and digital signature within the signatures.json file. If the package author has opted to publish their releases to the Apex Public Ledger the release signature will be further verified against the author's certificate found within the public ledger.

Help keep the PHP eco-system secure and free of code injection attacks. Contact your favorite Composer authors, and send them to the URL: https://apexpl.io/composer.