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
User accounts that can modify the source or the project’s configuration must use multi-factor authentication or its equivalent. This strongly authenticated identity MUST be used for the generation of source provenance attestations. The SCS MUST declare which forms of identity it considers to be trustworthy for this purpose. For cloud-based SCSs, this will typically be the identity used to push to a repository.
Other forms of identity MAY be included as informational. Examples include a git commit’s “author” and “committer” fields and a gpg signature’s “user id.” These forms of identity are user-provided and not typically verified by the source provenance attestation issuer.
This text makes some assumptions about the implementation of the SCS in that there exists some way to login and make changes to the source or its repository configuration. I'm not sure if it'd apply to cases such as git.kernel.org? Perhaps MFA should be an example of something that should be enabled if applicable?
On a related note, should we say what's an equivalent for MFA? is this an alternative for something like managing source configurations on a service such as GitHub? Or is the "equivalent" for cases like git.kernel.org where the configuration is managed in some other way and MFA may not apply?
There's some ambiguity in how the strongly authenticated identity is used in the generation of source provenance attestations. If this strongly authenticated identity is for the producer of the provenance attestation, then it may not meet the MFA requirement since we're looking at the signer of the attestation which may be a workflow identity? The sentence "this will typically be the identity used to push to a repository" contributes to the ambiguity, as it could be read to mean either the identity recorded in the provenance attestation or the identity associated with the signer of the provenance attestation.
I'm happy to open a PR for this but I'm curious to see what everyone thinks. 😄
The text was updated successfully, but these errors were encountered:
When working on #1265, I realized I have some questions about https://slsa.dev/spec/draft/source-requirements#strong-
authentication. The source track text currently says:
This text makes some assumptions about the implementation of the SCS in that there exists some way to login and make changes to the source or its repository configuration. I'm not sure if it'd apply to cases such as git.kernel.org? Perhaps MFA should be an example of something that should be enabled if applicable?
On a related note, should we say what's an equivalent for MFA? is this an alternative for something like managing source configurations on a service such as GitHub? Or is the "equivalent" for cases like git.kernel.org where the configuration is managed in some other way and MFA may not apply?
There's some ambiguity in how the strongly authenticated identity is used in the generation of source provenance attestations. If this strongly authenticated identity is for the producer of the provenance attestation, then it may not meet the MFA requirement since we're looking at the signer of the attestation which may be a workflow identity? The sentence "this will typically be the identity used to push to a repository" contributes to the ambiguity, as it could be read to mean either the identity recorded in the provenance attestation or the identity associated with the signer of the provenance attestation.
I'm happy to open a PR for this but I'm curious to see what everyone thinks. 😄
The text was updated successfully, but these errors were encountered: