Use build-and-inspect-python-package v2.12.0

[twm]

Description

For our glorious metadata future!

Checklist

• Make sure changes are covered by existing or new tests.
• For at least one Python version, make sure test pass on your local environment.
• Create a file in src/towncrier/newsfragments/. Briefly describe your
  changes, with information useful to end users. Your change will be included in the public release notes.
• Make sure all GitHub Actions checks are green (they are automatically checking all of the above).
• Ensure docs/tutorial.rst is still up-to-date.
• If you add new CLI arguments (or change the meaning of existing ones), make sure docs/cli.rst reflects those changes.
• If you add new configuration options (or change the meaning of existing ones), make sure docs/configuration.rst reflects those changes.

[glyph]

I will … have to take your word for it :).

Maybe @hynek should push some tags, so we don't pin to hashes, though?

[hynek]

there's plenty tags. some people like to to be extra-careful and pin actions to hashes.

[twm]

😂 I was just following the pattern, but FTR hynek/build-and-inspect-python-package@b5076c3

[adiroiban]

there's plenty tags. some people like to to be extra-careful and pin actions to hashes.

The pin hash might be my fault and my paranoia.

With all kind of supply chain actions, I thought that is a bit better to depend on a fixed code.

With the next PR touching this code, we can start using auto-updating tags.

There are so many ways in which one can implement a supply chain attach, that maybe nobody will consider hynek/build-and-inspect-python-package

[glyph]

There are so many ways in which one can implement a supply chain attach, that maybe nobody will consider hynek/build-and-inspect-python-package

The issue is less that this particular package isn't a target, as that anyone who can take over Hynek's repo and push arbitrary tags to it, can probably also execute a git hash collision; so it's not really a security measure, it's just less readable :)

[adiroiban]

can probably also execute a git hash collision;

Yes. Pinning is not bullet proof. My reasoning was that a hash collision will be more noticable, in comparison to updating a tag.

But we can start using tags. No problem.