Make dependencies optional

[jku]

I'm storing this draft plan here

Plan: Configurable Dependencies for tuf-on-ci

It would be good to allow users of tuf-on-ci GitHub Actions to select specific dependencies (like AWS, GCP, Azure, and Sigstore) to limit the installation overhead and reduce the (dependency injection) attack surface.

Exposing Dependency Configuration Options

Currently, tuf-on-ci installs all supported KMS and signing dependencies by default (via securesystemslib[awskms, azurekms, gcpkms, sigstore]). We could make these optional since almost no-one will want more than one KMS in use at a time

Option 1. Explicit feature flags for actions (with some shortcuts)

We likely need to expose these explicitly, either as a single input or per-KMS in most of our actions:

inputs:
  with_sigstore:
    description: "Enable Sigstore signing support"
    required: false
    default: "false"
  with_aws:
    description: "Enable AWS KMS support"
    required: false
    default: "false"
  with_gcp:
    description: "Enable GCP KMS support"
    required: false
    default: "false"
  with_azure:
    description: "Enable Azure Key Vault support"
    required: false
    default: "false"

We could still auto-enable features in e.g. online-sign but this just does not work in every case:

• AWS: Install aws extra if aws_role_to_assume or aws_region is provided.
• GCP: Install gcp extra if gcp_workload_identity_provider is provided.
• Azure: Install azure extra if azure_client_id is provided.

I'm not a big fan of this option since there is so much more "action API surface" for little gain.

Option 2. single features flag

The alternative would be a single option that takes a python "extras" list as argument

inputs:
  dependencies:
    description: "Enable different signing systems [gcp,aws,azure,sigstore]"
    required: false
    default: ""

This would likely be easier to implement

Implementation Details

Python Package Changes (repo/pyproject.toml)

Move the heavy dependencies to optional-dependencies:

[project]
dependencies = [
  "securesystemslib ~= 1.2",
  "tuf >= 5.1,< 7.0",
  "click ~= 8.1",
]

[project.optional-dependencies]
aws = ["securesystemslib[awskms]"]
azure = ["securesystemslib[azurekms]"]
gcp = ["securesystemslib[gcpkms]"]
sigstore = ["securesystemslib[sigstore]"]

Python Code Changes

The imports of SigstoreKey and SigstoreSigner in securesystemslib are safe
even without the sigstore extra installed. Therefore, no conditional
imports or code changes are required in tuf-on-ci.

Action Script Changes: Consider a Centralized Installation Action

If we use separate action inputs, the installation step becomes a complex shell script in multiple actions: creating
a centralized internal action for installation: actions/_install/action.yml might make sense.

This action will:

1. Accept all the flags and authentication inputs.
2. Contain the bash logic to compute the required EXTRAS.
3. Perform the pip install.

Other actions (like online-sign, upload-repository, etc.) will simply
call this local action, passing their inputs through.

Example of calling the centralized action:

- uses: ./actions/install
  with:
    with_sigstore: ${{ inputs.with_sigstore }}
    with_aws: ${{ inputs.with_aws }}
    aws_role_to_assume: ${{ inputs.aws_role_to_assume }}
    # ...

Alternatively, if we have a single "dependencies" input, then we can likely feed that directly to "uv/pip install".

Testability

Focus on install tests in CI to verify that:

• Base installation works and passes functional tests
• installation with different features works

---

Supply Chain Security Impact

• Reduced attack surface by avoiding installation of large, unused libraries.

Downsides

• Most actions will have new inputs that need to be set
• installation step in the actions might become more complicated

[jku]

Additional notes:

• this is somewhat out-of-date by now as everything uses uv at this point: I've not looked at how the installation would need to change to modify the "extras" value for securesystemslib
• option 2 above still sounds more reasonable
• We could even set the default value of the option 2 argument to mean "all signers": this way existing workflows continue to work without changes