Skip to content

Generate and add an SBOM to wheels (PEP 770)#130

Open
StanFromIreland wants to merge 4 commits intopython:masterfrom
StanFromIreland:sbom
Open

Generate and add an SBOM to wheels (PEP 770)#130
StanFromIreland wants to merge 4 commits intopython:masterfrom
StanFromIreland:sbom

Conversation

@StanFromIreland
Copy link
Copy Markdown
Member

@sethmlarson, could you please review?

@StanFromIreland
Copy link
Copy Markdown
Member Author

Ah, pathlib isn't in Python 2.7 🙃

Copy link
Copy Markdown

@sethmlarson sethmlarson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general this looks good to me, do you have the "built" SBOM available so I can poke around with it with some validators?

"$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json",
"version": 1,
"bomFormat": "CycloneDX",
"specVersion": "1.7",
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Funnily enough, many scanners don't recognize later SBOM versions. If you're not using new features it's better to use a lower version (like 1.4).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that's not ideal, IIRC since it has been a few days I think there was something only in the newer ones.

@StanFromIreland
Copy link
Copy Markdown
Member Author

Here are the extracted contents:

Details
tzdata-2026.1.dist-info/sboms$ cat sbom.cdx.json 
{
  "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json",
  "version": 1,
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "metadata": {
    "component": {
      "bom-ref": "pkg:pypi/tzdata@2026.1",
      "name": "tzdata",
      "version": "2026.1",
      "purl": "pkg:pypi/tzdata@2026.1",
      "type": "library",
      "components": [
        {
          "bom-ref": "https://www.iana.org/time-zones",
          "name": "tz",
          "version": "2026a",
          "type": "data",
          "data": [
            {
              "type": "dataset",
              "name": "IANA Time Zone Database",
              "description": "zic-compiled TZif timezone files"
            }
          ],
          "licenses": [
            {
              "license": {
                "name": "tz database license",
                "url": "https://data.iana.org/time-zones/tz-link.html"
              }
            }
          ]
        }
      ]
    }
  }
}

Copy link
Copy Markdown
Member

@pganssle pganssle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I could have sworn I left this comment already, but is there a way to do this without adding a setup.py? This is a very simple package, surely there is an existing backend that can handle packaging up a data-only package and including a SBOM automatically, or a plugin for setuptools for this?

@StanFromIreland
Copy link
Copy Markdown
Member Author

Not yet it seems per pypa/setuptools#4821.

Would you prefer we run generate_sbom during the update instead?

@pganssle
Copy link
Copy Markdown
Member

pganssle commented Apr 24, 2026

Not yet it seems per pypa/setuptools#4821.

Would you prefer we run generate_sbom during the update instead?

Yeah I looked into this a bit and it seems to me like the best ways forward are one of:

  • Use hatchling or maturin or something that supports this as a backend natively.
  • Use auditwheel repair to add this to the wheel after the fact
  • Wait until this is natively supported by setuptools or someone writes a plugin we can just use (I'm not sure we have a super strong impetus to do this right away, right?)

Also, I'm guessing based on the commit history that the setup.py seemed to need to maintain backwards compatibility with 2.7, but while I do think our completely data-only package should be able to maintain compatibility with all versions of Python ~indefinitely, we only really need an installed wheel to work, we don't need to be able to build the wheel with the older versions, so if it makes things easier, we can refactor the testing so that we have one job that builds a wheel using Python 3.13 or whatever, and all the other jobs just install that wheel, or maybe all non-EoL Python versions building from an sdist and all EoL versions just take the wheel built from Python 3.13 or 3.14 and use that for their testing.

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

Successfully merging this pull request may close these issues.

3 participants