Feature request: generate SLSA provenance

[agriyakhetarpal]

Summary

Hi there! I wonder if scicookie as a cookiecutter template could generate SLSA3 provenance for Python-based build artifacts (the source distribution and wheels) in the template files by default (or allow opt-in for users if they want it at the time of the creation of the project using the template, while recommending users to do this by default).

This serves two reasons:

1. Reproducibility of build artifacts with easily available metadata (provided with the release or on request by package authors, maintainers, or release managers)
2. Enhanced security measures across multiple software distribution levels

More details are at the https://github.com/slsa-framework/slsa-github-generator/ repository and this blog:
https://security.googleblog.com/2022/04/improving-software-supply-chain.html

https://github.com/sigstore/sigstore-python would also be a very viable method to sign artifacts.

Additional Information

Some instructions for creating a workflow that does this are available at: https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#provenance-for-python

scicookie can make use of the makim release.ci command to do this – not sure how @semantic-release will fit in with this, though.

For sigstore-python, there is a workflow in the GitHub Actions marketplace: https://github.com/sigstore/gh-action-sigstore-python

Code of Conduct

• I agree to follow the Code of Conduct

[xmnlab]

thanks @agriyakhetarpal for open this issue!

TBH I am not familiar with SLSA3, so I will take some time to read all the references before I can be able to answer it,

PS: btw, additionally to semantic release we could have other release tools as well.

[agriyakhetarpal]

PS: btw, additionally to semantic release we could have other release tools as well.

Yes – a CalVer bot integration, or even something like https://github.com/callowayproject/bump-my-version would be quite helpful as well (which would allow running through pipx). Thanks for looking into this!

[xmnlab]

@agriyakhetarpal , I think that it looks really nice.

I don't think I can work on that right now .. or maybe it would take too much time until I would be able to work on that. All these things are new to me, although I had read (only) an article in the past about sigstore ... but I have no experience with that or anything about SLSA.

is that something you could work on? or maybe do you know someone that could work on that?

I will be more than happy to guide anyone in terms of the scicookie structure.

in the scicookie structure I think it should be defined by default as disabled, so any maintainer could decide if they want to opt-in that as default or not. I think that it would be very nice to add it by default to osl profile, just not sure how it would work with semantic release (semantic-release/semantic-release#2913)

and of course, if you are a member of a community, we will be more than happy to have a profile for your community as well :) that is basically a yaml file with the configuration for the profile of your community, for example: https://github.com/osl-incubator/scicookie/pull/273/files

I hope that soon we will also have a flag for custom profiles locally as well.

let me know your thoughts about that, and thanks for raising this topic here.

[xmnlab]

@agriyakhetarpal , about the support for SLSA level 3 in semantic release, it seems it was not implemented yet.

[agriyakhetarpal]

@agriyakhetarpal , I think that it looks really nice.

I don't think I can work on that right now .. or maybe it would take too much time until I would be able to work on that. All these things are new to me, although I had read (only) an article in the past about sigstore ... but I have no experience with that or anything about SLSA.

about the support for SLSA level 3 in semantic release, it seems it was not implemented yet.

Thank you so much for your research, @xmnlab!

is that something you could work on? or maybe do you know someone that could work on that?

I am not sure if I will have enough bandwidth at this time to write an end-to-end solution that can cover all of what has been described – SLSA3 provenance is quite tricky, and while it is possible to implement a custom builder, there is indeed a lot of effort involved in doing so. However, for something like Sigstore, that should be doable, I can either write a PR myself, or step back and review a PR containing the implementation if someone else wishes to do it. On whether this should be disabled by default and that package authors should opt-in to doing this, I agree – not having it will simplify things.

and of course, if you are a member of a community, we will be more than happy to have a profile for your community as well :) that is basically a yaml file with the configuration for the profile of your community, for example: #273 (files)

Ah, I'm not sure I follow this fully – I have used SciCookie on a few personal/individual projects by now, but I am not using it as a part of a community so far. I am assuming this is meant for frequent users to have their configuration placed in-tree. However, this looks like a really handy feature!

I hope that soon we will also have a flag for custom profiles locally as well.

If you could standardise the schema for the YAML file, code editors and IDEs should be able to use that for syntax highlighting and error checking. It would also be great if a custom URL could be used (i.e., allowing the use of a profile from a raw GitHub URL hosted elsewhere, with something like scicookie --profile https://www.path.to/hosted/url/profile.yaml/).

[agriyakhetarpal]

See also, this is a new feature from GitHub: https://github.com/actions/attest-build-provenance

It it to be noted that this provides Level 2 (SLSA2) provenance, and not Level 3 (this is possible but it requires all workflows and actions-level dependencies to achieve that), but even a lower version would be a fair addition for adoption by users. I would be happy contribute towards adding Sigstore plus GitHub Actions attestations, if I can receive a go-ahead for this. I am not sure if similar features exist for other CI providers; however, based on #264, #265, #266 they are yet to be added to the template and thus can be explored at a later time.

[xmnlab]

@agriyakhetarpal that would be great! thanks!

I am just not sure yet how it would work ... so if you could share your plans here, I maybe could help you to define how it could be included into scicookie

[agriyakhetarpal]

Hi @xmnlab, I offer my apologies for such a late response! Your comment slipped through my notifications and I never realised you asked me for further plans – the GHA Attestations feature is now generally available at the time of writing for users and its integration should be smooth. Still, it works best with an action that publishes wheels to PyPI through OIDC-based trusted publishing, e.g., https://github.com/pypa/gh-action-pypi-publish/. This is so that attestations for wheels are built in a step before the upload and stored in https://github.com/myproject/myrepo/attestations/ for anyone to view and verify via the gh attestation verify command (during the job for wheel uploads). However, I don't see this action being used in release.yaml right now or elsewhere in the scicookie codebase, so we might have to either implement this for users who would like an alternative to semantic-release, or wait until semantic-release implements semantic-release/semantic-release#2913 as you previously linked. See also: https://learn.scientific-python.org/development/guides/gha-pure/, which has a concrete example of how such a workflow could look like (minus the Jinja, of course).