Note that p11-kit doesn't use a git tag, but a specific commit instead. MitM attacks using a forged git repository with different content for the same commit id is nearly impossible.

upstream signatures are not quite against a MitM but authenticate the author that its indeed what the author created. F.e. you can be tricked to update it to a new commit when the server was hacked without you noticing that its not from the original software author.
Its unlikely/ hardly possible to make this specific commit go evil but that doesn't replace what authentication provides. If that would be like this, we can purge all signatures when we use secure hashes?

Why not use the same code the systemd PKGBUILD uses to validate a git tag until it is formally integrated in makepkg?

1) The systemd PKGBUILD is not validating anything, it is all security theater. If we are going to build against specific commits, those commits need to be signed by upstream.
Saying "oh, trust that the package maintainer PGP-verified the latest tag and scrutinized all the numerous commits since then to see what precisely they were doing" is not, in fact, PGP.
So, bad example. :p
That being said, it can certainly be used to verify the actual build tag... but why? tarballs work fine too, and more simply. Looking through the history of this package, we've never actually built from anything other than a tag...

2) validating a commit sha1 hash is no more or less secure than using sha1sums=() for a tarball release. It's nice, but also completely missing the point of using PGP.

I much prefer building from Git as tarballs often contain more files, whose state is dependent on the developer's machine. For example, prebuilt build utils (autotools), documentation (gtk-doc), or code (vala).

Building from a clean tree with *our* packaged tools has more value to me than code signing.

In addition, it is easier to pick commits between releases or cherry-pick individual commits as patches.

thats perfect, then we can use the tarballs that are signed on github as they are unprocessed in its source files and 100% identical to the repo sources. the toolchains can create the things freshly, doesn't exclude each other and hard to spot a real example for this one that truly justifies to ignore neat signatures aka authenticated sources.

Unfortunately, this is false. For each release, p11-kit on GitHub provides four files:

p11-kit-$ver.tar.gz
p11-kit-$ver.tar.gz.sig
Source code (zip)
Source code (tar.gz)

The signed tar is dirty, as I mentioned. The clean "Source code" archives are unsigned.

you are misinterpreting it, the sources are fully there (not altered, not stripped regardings tests or anything) the toolchain can freely just make whatever you wish as f.e. autoreconf. i mean there is no example in this one that harms using the signed version.

any updates? I can prepare a PKGBUILD patch for you if its too much hassle. I sehe where you are coming from, but that really don't apply much in this case.

In the meanwhile regarding authenticated sources, i gonna leave this his here :)
https://archives.gentoo.org/gentoo-dev/message/03df77a347ec75a9b1ceaab3a2f76ee8
https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hacked.html

Tried giving signed tags a try; check trunk.

Looks great, thanks.

If you want to use pinned commit hashes as well, maybe try asking upstream if they can sign their commits as well as tags?