Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print artifact digest after build process is completed #789

Open
elad-pticha opened this issue Jun 18, 2024 · 6 comments
Open

Print artifact digest after build process is completed #789

elad-pticha opened this issue Jun 18, 2024 · 6 comments

Comments

@elad-pticha
Copy link

elad-pticha commented Jun 18, 2024

I think it would be beneficial to add artifact digests to the Successfully built message. For instance:

Successfully built test-0.0.0.tar.gz@sha256:960b9adda66023aed657c0da9626a6b8de71e433843181a5397431465adb57a7 and test-0.0.0-py3-none-any.whl@sha256:c856716babc6d603769f6b4f1a7122a61b870e7f627b0e2b4aa8f48b712c7770

image

Including the digest information strengthens the link between the build system and the package repository.

Let's take, for example, a GitHub Actions pipeline that builds and pushes packages to PyPI. Users can check the package's hash in the package repository but have no idea if that artifact is really built from the source repository it claims to be related to. If a digest is printed at the end of the build process, it could indicate that the package in the package registry has been created in a specific build pipeline.

This also relates to the world of SLSA and artifact integrity, allowing users to link between an artifact to its source.

@elad-pticha
Copy link
Author

If you think this is a good idea, I can submit a PR to implement it.

@henryiii
Copy link
Contributor

henryiii commented Jun 19, 2024

I’d like to have a machine readable output (json probably), but it can’t (only) be printed, since it is problematic to try to pick it out of stdout. Probably an argument that allows writing the built package info to a stream or file. Having the name(s) and maybe other info is useful too when building pipelines.

@henryiii
Copy link
Contributor

If you had such a machine readable output, then you could process it and produce the digest in your preferred format. No need to make a list of formats.

@elad-pticha
Copy link
Author

I agree, but this still does not address my main concern.

When downloading packages from PyPI or other package managers, I can see the digests of the artifacts, but there is no way to verify that they are trustworthy and haven't been tampered with.

I believe the community would greatly benefit from being able to inspect the build workflow, specifically at the python -m build command, to ensure that the package in the registry was created by the claimed repository.
Including this in a separate flag would depend on the project owner to incorporate it into their pipelines.

By printing the digest by default, it would enable users to establish a connection from the source to the build.

@henryiii
Copy link
Contributor

This is being worked on in https://peps.python.org/pep-0740/. You can already sign artifacts and have GitHub host the attentions, see #782 and the examples linked from there (we have not made a release yet with our own attestations). Build logs are not a good place to put security information. They aren’t always visible and are deleted over time.

@elad-pticha
Copy link
Author

elad-pticha commented Jun 23, 2024

I agree that build logs are not a place to put security information and that this does not come any close to creating a proper SLSA attestation, but maybe it is better than having no information at all for projects that don't produce attestations.

Another option is that this issue should be under the twine repository and that the digest should be printed after the package has been pushed.

WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants