make_signed_source

# Workflow `make_signed_source`

This workflow produces a source package with signed contents from a template package and some binary packages.

- `task_data`:

  - `binary_artifacts` (Multiple lookup, required): the debian:binary-package or debian:upload artifacts representing the binary packages to sign

  - `signing_template_artifacts` (Multiple lookup, required): the debian:binary-package artifacts representing the binary packages to sign

  - `vendor` (string, required): the distribution vendor on which to sign

  - `codename` (string, required): the distribution codename on which to sign

  - `architectures` (list of strings): the list of architectures that this workflow is running on, plus `all`

  - `purpose` (string, required): the purpose of the key to sign with; see Sign

  - `key` (string, required): the fingerprint to sign with; must match `purpose`

  - `sbuild_backend` (string, optional): see PackageBuild

The workflow computes dynamic metadata as:

- subject: source package names separated by spaces

- parameter_summary: source package names separated by spaces followed by “for `vendor`:`codename`”

- binary_artifacts_ids: ids of the binary_artifacts

- signing_template_artifacts_ids: ids of the signing_template_artifacts

Any of the lookups in `binary_artifacts` or `signing_template_artifacts` may result in promises, and in that case the workflow adds corresponding dependencies. Promises must include an `architecture` field in their data, and signing template promises must also include a `binary_package_name` field.

The list of architectures to run on is the list of architectures that are present in both `binary_artifacts` and `signing_template_artifacts`, intersected with `architectures`.

For each architecture and for each artifact from `signing_template_artifacts` matching that architecture, the workflow creates sub-workflows and tasks as follows, with substitutions based on its own task data. Each one has a dependency on the previous one in sequence, using event reactions to store output in the workflow’s internal collection for use by later tasks:

- an ExtractForSigning task, with task data:

  - `input.template_artifact`: the subset of the lookup in this workflow’s `signing_template_artifacts` for the concrete architecture in question

  - `input.binary_artifacts`: the subset of the lookup in this workflow’s `binary_artifacts` for each of `all` and the concrete architecture in question that exist

  - `environment`: `{vendor}/match:codename={codename}`

- a Sign task, with task data:

  - `purpose`: `{purpose}`

  - `unsigned`: the output of the previous task, from the workflow’s internal collection

  - `key`: `{key}`

- an AssembleSignedSource task, with task data:

  - `environment`: `{vendor}/match:codename={codename}`

  - `template`: the subset of the lookup in this workflow’s `signing_template_artifacts` for the concrete architecture in question

  - `signed`: the output of the previous task, from the workflow’s internal collection

- an sbuild sub-workflow, with task data:

  - `prefix`: `signed-source-{architecture}-{signing_template_name}|`

  - `input.source_artifact`: the output of the previous task, from the workflow’s internal collection

  - `input.extra_binary_artifacts`: the subset of the lookup in this workflow’s `binary_artifacts` for each of `all` and the concrete architecture in question that exist

  - `target_distribution`: `{vendor}:{codename}`

  - `backend`: `{sbuild_backend}`

  - `architectures`: if `{architectures}` is set, then `{architectures}` plus `all`

The workflow adds event reactions that cause the debian:upload artifacts in the output for each architecture and signing template name to be provided as `signed-source-{architecture}-{signing_template_name}` in the workflow’s internal collection.

Todo

We may need to use different keys for different architectures. For example, a UEFI signing key is only useful on architectures that use UEFI, and some architectures have other firmware signing arrangements.