I've just made public this repo where I am publishing materials for this project: https://github.com/sethmlarson/sboms-for-python-packages
#sboms
grizzled merlin
lean coral
Would summarising the status quo be in scope for this project? I posted that as a question on the issue tracker: https://github.com/sethmlarson/sboms-for-python-packages/issues/7
While it's a long way from the top of my TODO list, I'm assuming generating SBOMs for environment stack layers will eventually become a functional requirement for venvstacks
upper pilot
one thing that would surely help with making SBOMs easier to implement in package managers/build backends is a simple and lightweight library for that. I wanted to add attestations generation to Poetry, but the libraries were hauling behind a long list of dependencies which are too big of a cost for too little gain
lean coral
Hah, now I'm wondering how long it will be before we see a software supply chain attack on software supply chain management tooling (assuming there hasn't been one already).
upper pilot
something like that has probably already happened
grizzled merlin
@upper pilot Could you add your previous experience to: https://github.com/sethmlarson/sboms-for-python-packages/issues/7
I think it's an important story to tell, also to forward along the feedback to SBOM libraries that exist already. I'm kinda in agreement that they are very heavy-weight for what they do.
upper pilot
<@286253769736585216> Could you add your previous experience to: https://github....
done. let me know if you need me to add/clarify something
grizzled merlin
Ah that is attestations not SBOMs! SBOMs are listing out what is in the package where attestations are about where packages came from
upper pilot
yeah, those are different, but that still could be the case when it comes to dependency-heavy libraries
grizzled merlin
Got it! Okay, I'll definitely evaluate that as a part of the SBOM library work.
grizzled merlin
I've opened a discussion thread on discuss.python.org for the project announcement: https://discuss.python.org/t/sboms-for-python-packages-project/70261
grizzled merlin
Forgot to share here, I published some positive early findings on adding SBOM to Python packages w/ auditwheel: https://sethmlarson.dev/early-promising-results-with-sboms-and-python-packages
grizzled merlin
Happy new year! I've opened the discussion into the SBOMs-in-Python-packages PEP: https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308
grizzled merlin
Hey folks who might have stopped watching the thread above since things have simmered down. We discovered there's a bit of a hitch for projects that have many SBOM sources (static, dynamic, post-build) wrt the dynamic keyword. To avoid that, we've discussed an approach using a named directory under .dist-info/sboms be the primary method that an SBOM is specified rather than using a core metadata field (this handles build backend and post-build tools creating SBOMs) and then having a different mechanism to specify files to that directory statically. From an SBOM consumer POV nothing changes, from an SBOM generator POV nothing changes, but it is a difference compared to the original design that's been around for a while.
So if you're interested in taking another look, this comment is a good place to start (https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/71) to see the changes to the PEP then you can see the pre-conversation and where we're at now below.
grizzled merlin
Hey folks, there's only one thing left on PEP 770, what to name the table for statically defining files that end up in .dist-info/<dir> from pyproject.toml, if you're interested please take a look and vote: https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/103
Without a clear indicator I'll be refactoring this section out of the current PEP so the rest can proceed.
zealous field
been a bit out of it but glad this is progressing - for rebuilders and distros like$DAYJOB I suspect the dir not metadata approach works well and could start using quickly. No strong opinion on the table as that’s more tool facing I imagine but would prefer getting this through to getting stuck on
have had a lot of life stuff so not been active on the discussion thread
also felt weird weighing in after a long gap in python community work but voted now
grizzled merlin
Happy to share that PEP 770 has been accepted: https://peps.python.org/pep-0770/
Thanks to @smoky crypt and everyone who left feedback! 💜
upper pilot
that was pretty fast
smoky crypt
that was pretty fast
How was it fast?
upper pilot
How was it fast?
I mean, it was pretty fast new-to-accepted, at least that is how it feels for me
smoky crypt
I mean, it was pretty fast new-to-accepted, at least that is how it feels for me
It took 3 months; it's not fast or slow. It's also a simple PEP in the end.
upper pilot
my comment didn't have any special meaning behind it. I am not up to date with all the PEPs and how long they take to get accepted, so it's just my personal feeling of the passing time 😅
lean coral
In this case, there was a non-controversial-and-still-useful subset, so this PEP was reduced to that (now accepted) scope, and the more debatable bits will be revisited in a follow up proposal later in the year.
Many PEPs can't be neatly subdivided like that, so the whole thing remains in draft until all the niggling details get resolved.
grizzled merlin
blissful raptor
@grizzled merlin @viral minnow @smoky crypt I had a thought at PyCon sprint about security-related thing we might want to surface in metadata (along with the import name metadata Brett is currently proposing). We started using pre-commit-uv, which patches pre-commit to use uv. It does that "invisibly", you simply install pre-commit-uv and pre-commit gets patched. The package includes a .pth file which patches the other library. It seems like we should be surfacing the fact that a package installs .pth files more prominently. It's intentional with pre-commit-uv, but malicious packages/changes could do much sneakier things.
Figured this channel was a somewhat relevant place to post about this, but I can move elsewhere.
charred fulcrum
<@481989102951202817> <@292772972047892481> <@377660079509340163> I had a though...
Would metadata surfacing help that if it was in the sdist?
blissful raptor
Maybe I’m misunderstanding what you’re asking, but that’s what I suggested
charred fulcrum
I mean, there isn't a 100% surefire way to specify metadata in the sdist afaict
It can be possible for a tool to read a path file in a wheel, but there's no reassurances if it's an sdist
viral minnow
smoky crypt
But something that old won't have SBOMs either, so that doesn't seem to be a concern for this topic.
ancient kettle
true, I'm happy if those messages are moved; I wasn't really paying attention to the channel
smoky crypt
true, I'm happy if those messages are moved; I wasn't really paying attention to...
Can you move them yourself?