-
Notifications
You must be signed in to change notification settings - Fork 123
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
Comments
If you think this is a good idea, I can submit a PR to implement it. |
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. |
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. |
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 By printing the digest by default, it would enable users to establish a connection from the source to the build. |
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. |
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? |
I think it would be beneficial to add artifact digests to the Successfully built message. For instance:
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.
The text was updated successfully, but these errors were encountered: