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
Once the signing request is successfully completed, the status response contains a `signedArtifactLink` field with a link to the signed artifact file. It can easily be retrieved by issuing the following command:
150
150
151
-
| Synopsis ||
152
-
|------------|------|
151
+
| Synopsis |
152
+
|------------|------
153
153
| URL | `/SigningRequests/$(SigningRequestId)/SignedArtifact` <br> (`signedArtifactLink` field from `GET SigningRequests/`id)
| **Approvers** | Select the users that are allowed to approve signing requests. They will receive e-mail notifications for each request.
66
66
| **Required approvals** | Set how many approvals are required. Note that a single _deny_ will abort the request. (Also known as _quorum_ or _k-out-of-n approval_.) | {{ site.data.editions | where: "policy_enforcement.quorum_approval", "true" | map: "name" | join: ", " }}
67
67
@@ -82,7 +82,7 @@ Select **Verify origin** if you want to accept only signing requests with positi
82
82
[Trusted build system verification](#signing-policy-trusted-build-system) must be enabled for origin verfication.
| **Project repository URL** | Must be configured in the project settings (applies to all signing policies)
87
87
| **Allowed branch names** | For release-signing, it is recommended to restrict the signing policy to release branches, such as `main` or `release/*`. This helps to enforce a code review policy for release builds and prevents accidental or intentional release-signing of internal and test builds.
Copy file name to clipboardExpand all lines: docs/slsa-attestations/definitions.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -116,8 +116,8 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
116
116
{:.quote}
117
117
> It MUST NOT be possible for two builds that overlap in time to influence one another, such as by altering the memory of a different build process running on the same machine.
118
118
119
-
| Build System | Guarantee|
120
-
| -- |------------------------------|
119
+
| Build System | Guarantee
120
+
|----------------|------------------------------
121
121
| 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
122
| 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
123
@@ -126,8 +126,8 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
126
126
{:.quote}
127
127
> 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.
128
128
129
-
| Build System | Guarantee|
130
-
| -- |------------------------------|
129
+
| Build System | Guarantee
130
+
|----------------|------------------------------
131
131
| 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
132
| 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
133
@@ -136,8 +136,8 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
136
136
{:.quote}
137
137
> 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
138
139
-
| Build System | Guarantee|
140
-
| -- |------------------------------|
139
+
| Build System | Guarantee
140
+
|----------------|------------------------------
141
141
| 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
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
143
@@ -146,8 +146,8 @@ Guarantee: If the provenance is signed by SignPath, the build was executed on a
146
146
{:.quote}
147
147
> The build platform MUST NOT open services that allow for remote influence unless all such interactions are captured as externalParameters in the provenance
148
148
149
-
| Build System | Guarantee|
150
-
| -- |------------------------------|
149
+
| Build System | Guarantee
150
+
|----------------|------------------------------
151
151
| 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
152
| 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))
0 commit comments