You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/_data/changelog.yml
+10Lines changed: 10 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -18,6 +18,16 @@
18
18
- text: |-
19
19
Added new mandatory `appSettings.shared.contactOptions.supportEmailAddress` configuration in `signpath-application` chart. Rendered as support contact in error messages.
@@ -120,8 +118,7 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
120
118
|----------------|------------------------------
121
119
| Azure DevOps | The build was executed on a runner from the Microsoft-hosted pools, which offer isolation (see [the official documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/security/misc))
122
120
| GitHub Actions | The build was executed on a GitHub-hosted runner, each job is run in a fresh instance of the runner image (see [the official documentation](https://docs.github.com/en/actions/how-tos/manage-runners/github-hosted-runners/use-github-hosted-runners))
123
-
124
-
<!--| GitLab CI/CD | The build was executed on a GitLab-hosted runner, each job runs in a newly provisioned VM (see [the oficial documentation](https://docs.gitlab.com/ci/runners/hosted_runners/))-->
121
+
| GitLab CI/CD | The build was executed on a GitLab-hosted runner, each job runs in a newly provisioned VM (see [the oficial documentation](https://docs.gitlab.com/ci/runners/hosted_runners/))
125
122
126
123
{:.quote}
127
124
> It MUST NOT be possible for one build to persist or influence the build environment of a subsequent build. In other words, an ephemeral build environment MUST be provisioned for each build.
@@ -130,18 +127,16 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
130
127
|----------------|------------------------------
131
128
| Azure DevOps | The build was executed on a runner from the Microsoft-hosted pools, which provide a clean virtual machine for each build run (see [the official documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/security/misc))
132
129
| GitHub Actions | The build was executed on a GitHub-hosted runner, each job is run in a fresh instance of the runner image (see [the official documentation](https://docs.github.com/en/actions/how-tos/manage-runners/github-hosted-runners/use-github-hosted-runners))
133
-
134
-
<!--| GitLab CI/CD | The build was executed on a GitLab-hosted runner, each job runs in a newly provisioned VM (see [the oficial documentation](https://docs.gitlab.com/ci/runners/hosted_runners/))-->
130
+
| GitLab CI/CD | The build was executed on a GitLab-hosted runner, each job runs in a newly provisioned VM (see [the oficial documentation](https://docs.gitlab.com/ci/runners/hosted_runners/))
135
131
136
132
{:.quote}
137
133
> It MUST NOT be possible for one build to inject false entries into a build cache used by another build, also known as “cache poisoning”. In other words, the output of the build MUST be identical whether or not the cache is used.
138
134
139
135
| Build System | Guarantee
140
136
|----------------|------------------------------
141
137
| Azure DevOps | Cache usage has to be explicitly defined in the pipeline definition and cannot be shared across pipelines or branches (see [the official documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops&tabs=bundler#cache-isolation-and-security))
142
-
| GitHub Actions | Cache usage has to be explicitly defined in the workflow definition (see [the official definition](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching))
143
-
144
-
<!--| GitLab CI/CD | TODO: https://docs.gitlab.com/ci/caching/, see SIGNVM-114-->
138
+
| GitHub Actions | Cache usage has to be explicitly defined in the workflow definition (see [the official documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching))
139
+
| GitLab CI/CD | Cache usage has to be explicitly defined in the pipeline definition (see [the official documentation](https://docs.gitlab.com/ci/caching/)
145
140
146
141
{:.quote}
147
142
> The build platform MUST NOT open services that allow for remote influence unless all such interactions are captured as externalParameters in the provenance
@@ -150,8 +145,7 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
150
145
|----------------|------------------------------
151
146
| Azure DevOps | The build was executed on a runner from the Microsoft-hosted pools, which do not provide the ability to remotely connect (see [the official documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted)).
152
147
| GitHub Actions | The build was executed on a GitHub-hosted runner which does not provide the ability to remotely connect, unless explicitly specified in the build definition (see [the official documentation](https://docs.github.com/en/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network))
153
-
154
-
<!--| GitLab CI/CD | The build was executed on a GitLab-hosted runner wich does not allow remote connections (see [the official documentation](https://docs.gitlab.com/ci/runners/hosted_runners/))-->
148
+
| GitLab CI/CD | The build was executed on a GitLab-hosted runner wich does not allow remote connections (see [the official documentation](https://docs.gitlab.com/ci/runners/hosted_runners/))
* Use the predefined Trusted Build System _GitLab.com_ (see [configuration](/documentation/trusted-build-systems#configuration))
12
+
* add it to the Organization
13
+
* link it to each SignPath Project for GitLab
14
+
15
+
{:.panel.info}
16
+
> **Self-managed installations**
17
+
>
18
+
> SignPath hosts an instance of the GitLab connector which is linked to GitLab.com For integrating self-managed GitLab instances, contact our [support](https://signpath.io/support) team.
19
+
20
+
## Checks performed by SignPath
21
+
22
+
The GitLab connector performs the following checks:
23
+
24
+
* The artifact was built by a GitLab Pipeline, not by some other entity in possession of the API token
25
+
*[Origin metadata](/documentation/origin-verification) is provided by GitLab, not the build script, and can therefore not be forged
26
+
* The artifact is stored as a GitLab pipeline artifact before it is submitted for signing
27
+
28
+
## Usage
29
+
30
+
We provide a `submit-signing-request` component that can be integrated into a GitLab Pipeline:
See the [parameter list](#supported-parameters) for a complete list of all supported inputs.
59
+
60
+
{:.panel.info}
61
+
> **Signing multiple files**
62
+
>
63
+
> If you want to sign multiple files in a single signing request, you have to create and publish a dedicated ZIP archive in your build step and modify your artifact configuration on SignPath accordingly.
64
+
65
+
{:.panel.info}
66
+
> **Setups that don't include _Docker Executors_**
67
+
>
68
+
> For all organizations that don't support _Docker Executors_, we provide a CLI tool can be directly invoked. Please contact our [support team](https://signpath.io/support) for details.
| `stage` | `sign` | The GitLab pipeline stage at which the component should be executed.
75
+
| `job_name` | `submit-signing-request` | The name of the given signing job.
76
+
| `connector_url` | `https://gitlab.connectors.signpath.io` | The URL of the SignPath connector. Required if self-managed.
77
+
| `api_token_var_name` | `SIGNPATH_API_TOKEN` | The _Api Token_ for a user with submitter permissions in the specified project/signing policy. The component only allows providing the token via an environment variable. The name of the environment variable can be overwritten using this input.
78
+
| `gitlab_access_token_var_name` | `SIGNPATH_GITLAB_ACCESS_TOKEN` | The _GitLab Access Token_ that is used to retrieve [origin metadata](/documentation/origin-verification) from the GitLab instance. Requires the `read_api` scope. The component only allows providing the token via an environment variable. The name of the environment variable can be overwritten using this input.
79
+
| `organization_id` | (mandatory) | The SignPath organization ID.
80
+
| `project_slug` | (mandatory) | The SignPath project slug.
81
+
| `signing_policy_slug` | (mandatory) | The SignPath signing policy slug.
82
+
| `artifact_configuration_slug` | | The SignPath artifact configuration slug.
83
+
| `gitlab_artifact_job_name` | (mandatory) | The name of the job that published the artifact to be signed.
84
+
| `gitlab_artifact_path` | (mandatory) | The path within the GitLab artifact.
85
+
| `output_artifact_path` | | Path to where the signed artifact will be stored. If not specified, the task will not download the signed artifact from SignPath.
86
+
| `wait_for_completion` | `true` | Wait for the signing request to complete. If set to true, the signed artifact will be published.
87
+
| `parameters` | | List of key/value pairs that map to [user-defined parameters](/artifact-configuration/syntax#parameters) in the Artifact Configuration.
88
+
| `wait_for_completion_timeout_in_seconds` | `600` | Maximum time in seconds that the job/tool will wait for the signing request to complete.
89
+
| `service_unavailable_timeout_in_seconds` | `600` | Total time in seconds that the job/tool will wait for a single service call to succeed (across several retries).
90
+
| `download_signed_artifact_timeout_in_seconds` | `300` | HTTP timeout when downloading the signed artifact.
0 commit comments