conformance's Introduction

PHP-TUF

IMPORTANT

PHP-TUF is in a pre-release state and is not considered a complete or secure version of the TUF framework. It should currently only be used for testing, development and feedback.

Do not use in production for secure target downloads!!

PHP-TUF is a PHP implementation of The Update Framework (TUF) to provide signing and verification for secure PHP application updates. Read the TUF specification for more information on how TUF is intended to work and the security it provides.

PHP-TUF project development is primarily focused on supporting secure automated updates for PHP CMSes, although it should also work for any PHP application or Composer project. Contributing projects:

PHP-TUF client requirements

The PHP-TUF client is designed to provide TUF verification to PHP applications for target signatures.

Minimum required PHP version: 8.1
Requires ext-json
The paragonie/sodium_compat dependency provides a polyfill for the Sodium cryptography library; however, installing ext-sodium is recommended for better performance and security.

Code style

The code generally follows PSR-2 with some additional formatting rules for code documentation and array formatting. Run PHPCS to check for code style compliance:

 composer phpcs

Testing

Test fixtures generation

Run the following command:

   composer fixtures

Fixtures should appear in fixtures/.

Running the PHP-TUF tests

Ensure you have all required dependencies by running composer install.
Run composer test at the project's root.

Dependency policies and information

To provide a lightweight, reliable, and secure client, external dependencies are carefully limited. Any proposed dependency additions (and those dependencies' dependencies) should undergo the Drupal core dependency evaluation process.

For evaluations and policies of current dependencies, see the PHP-TUF dependency information.

Resources

conformance's People

Contributors

Watchers

conformance's Issues

Trusted and latest root metadata are expired

Description: This should be a simple fixture with server- and client-side metadata. The root metadata in both directories should have a date way in the past, to guarantee that it is expired and cannot be updated. The server-side metadata should have an additional version, in which the root metadata should have an expiration date that is later than the previous version, but still expired.

Procedure: TBD; I'm not clear yet on how to manually modify the expiration date of any given piece of metadata, beyond forcibly re-signing it. We will likely need to publish the fixture twice (once with the client, once without) in order to create a new version of the server-side metadata.

Expected Outcome: The TUF client should fail because the most recent available root metadata is expired.

No trusted root metadata available on the client side

Description: This fixture should contain only a directory of trusted client-side metadata. That directory should be missing root metadata.

Procedure: Initialize a fixture; there's no need to add any targets. Publish it with the client, then delete the server directory, and delete the root file from the client directory.

Expected Outcome: The TUF client should fail because it cannot load the trusted root metadata.

Too-big server-side root metadata

Description: This fixture does not need any targets, but it should have server-side and client-side metadata. There should be a second version of the server-side metadata, and its root metadata should just be a garbage file of 120KB or more of random characters.

Procedure: Generate a simple fixture. No need to add targets to it. Publish it once, with the client, and then publish it again, without the client. Replace the second version's root metadata with a file filled with randomly-generated text, and make it unreasonably large (at least 120 KB).

Expected Outcome: The TUF client should fail trying to fetch the new root metadata, because it's too big.

Trusted root metadata is expired and no more recent version is available

Description: This should be a simple fixture with server- and client-side metadata. The root metadata in both directories should have a date way in the past, to guarantee that it is expired and cannot be updated.

Procedure: TBD; I'm not clear yet on how to manually modify the expiration date of any given piece of metadata, beyond forcibly re-signing it.

Expected Outcome: The TUF client should fail because the most recent available root metadata is expired.

Recommend Projects

php-tuf / conformance Goto Github PK