Skip to content

Fix attach SBOM to GitHub release again #10275

Closed

Description

@aclark4life

Release improvement TODO:

Despite #9748, the first SBOM job failed because there was no release yet:

https://github.com/python-pillow/Pillow/actions/runs/38960170632/job/117219912710

I did the usual GH Release publish then reran it.

We need some improvement here. And it'd need to work with Release Drafter guessing the next is 12.4.0 when it's really 13.0.0.

Originally posted by @hugovk in #9885

Activity

  1. radarhere commented on Oct 22, 2026

    @radarhere
    Member

    Release Drafter guessing the next is 12.4.0 when it's really 13.0.0

    Looking at https://github.com/release-drafter/release-drafter#version-resolver, I found that we can change our config so that merging a PR with a particular label, say "Major", will cause release-drafter to bump up to the next major version. See #10279. We could simply label the first PR with the 14.0.0 release notes this way.

  2. radarhere commented on Oct 22, 2026

    @radarhere
    Member

    Despite #9748, the first SBOM job failed because there was no release yet:

    https://github.com/python-pillow/Pillow/actions/runs/38960170632/job/117219912710

    Wouldn't the simple solution be to wait until the rest of the files are uploaded (pypi-publish) and then upload the SBOM? I've created #10280

  3. hugovk commented on Oct 22, 2026

    @hugovk
    Member

    It's about the GitHub "Release" and not the tag. So https://github.com/python-pillow/Pillow/releases/tag/13.0.0 is the last published one, and https://github.com/python-pillow/Pillow/releases/tag/untagged-54142edae7b958b75f1c is the next unpublished one.

    The problem is the Release hasn't been published yet during the wheel workflow, and per RELEASING.md it's a manual step after the files have been uploaded.

    We could automate publishing (and with the merge of #10279, this is a good idea), but I have another idea.

    We originally decided to put the SBOM in the Release as a stopgap because we didn't have it embedded in wheels yet: #9550 (comment).

    But #9679 does embed it into wheels, so shall we just skip trying to upload it to the Release? Most Python projects don't put any release assets there, they all go to PyPI.

  4. hugovk commented on Oct 22, 2026

    @hugovk
    Member

    Separately, let's turn this on at https://github.com/python-pillow/Pillow/settings

    • Enable release immutability Loading
      Disallow assets and tags from being modified once a release is publish

    This would prevent uploading files after the Release is published.

    Even if we don't put assets there, disabling it would potentially prevent an attacker adding malicious wheels there. We can still edit the description.

  5. radarhere commented on Oct 22, 2026

    @radarhere
    Member

    shall we just skip trying to upload it to the Release? Most Python projects don't put any release assets there, they all go to PyPI.

    If that's the standard, then sure.

    Enable release immutability Loading

    Sounds good

  6. hugovk commented on Oct 22, 2026

    @hugovk
    Member

    I've enabled release immutability at https://github.com/python-pillow/Pillow/settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions