Seems fine to me. The generated files are the SBOM containing the hashes of these files.

@sethmlarson What's the way we should handle this kind of in-repo patching? Is regenerating the SBOM enough? Or do we need to track the before/after state as well? (Apologies for the incorrect tag if you see this, other-Seth)

@zooba I think it's fine that we make minor in-source changes, we run the risk of losing them when the dependency is updated so we should try to upstream the changes too. In a perfect world we'd be marking our SBOM with precise patches/descendants relationships, but I'm not sure how important that is for our primary use-case which is vulnerability management/discovery.

Okay, so this one is a backport from upstream so we won't lose it. We just need the SBOM to be regenerated to be able to merge the PR. I believe there's an open PR adding that functionality to the Windows build, so we'll probably have to wait for that to be merged before this can be updated.

@zooba, I have updated sbom files as requested

@zooba, let's merge it.

Thanks@georgthegreat for the PR, and@zooba for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12.
🐍🍒⛏🤖

Sorry,@georgthegreat and@zooba, I could not cleanly backport this to3.11 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 9b9e819b5116302cb4e471763feb2764eb17dde8 3.11

GH-116315 is a backport of this pull request to the3.12 branch.

@georgthegreat Is this needed for 3.11? Could you prepare a PR for that branch? I suspect it's the SBOM conflicting, but maybe it's not needed for an older version of blake2.

We do not need it in our codebase as we have switched to 3.12, so it is up to you to decide.
Do you consider this bug critical?

Do you consider this bug critical?

Nope :) But it wasn't critical to me in main either, so that's not a great bar for whether to backport. Happy to defer to your needs, and if someone else needs it for 3.11 then they can prepare a backport.