[Feature Request] Add .SRCINFO integrity check argument

[pricklythorn]

Is your feature request related to a problem? Please describe.

Considering that .SRCINFO is not diffed, a malicious packager could insert malware into .SRCINFO, of which yay will trust.

Describe the solution you'd like

One of two methods:

• At build time, .SRCINFO could be regenerated with makepkg, and diffed against the provided .SRCINFO.
• Provided .SRCINFO is ignored and regenerated from PKGBUILD.

Describe alternatives you've considered

Including .SRCINFO in diffing, but that would require you to carefully examine both the PKGBUILD and .SRCINFO for if they match, which could be automated.

Additional context

None.

[Jguer]

How would .SRCINFO malware be executed?
running makepkg would probably be more dangerous if you have not ascertained the safety of the repository at that point

[pricklythorn]

A malicious dependency or source link. Yeah that's fair.

[github-actions]

🤖 This is an automated response from Repo Assist.

The concern is valid as an integrity check, but .SRCINFO is metadata parsed by go-srcinfo; it is not executed as shell code. The security-sensitive point is that yay uses it to choose package names, dependencies, source URLs, and PGP keys before makepkg runs. Regenerating it with makepkg would execute the repository’s PKGBUILD earlier, so it is not a safe validation primitive by itself.

A lower-risk design would be an opt-in verification step after the repository is downloaded: run makepkg --printsrcinfo in the normal build context, compare the generated metadata with the committed .SRCINFO, and stop on differences. That should be treated as a separate integrity check rather than silently replacing the existing metadata path, since generated output can vary with architecture and makepkg configuration.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@1c6668b751c51af8571f01204ceffb19362e0f66

[pricklythorn]

This could also close #2888 as .SRCINFO would not need to be diffed. Wouldn't regenerating it from the PKGBUILD still be a solution as you would diff it first, then regenerate it?

[github-actions]

🤖 This is an automated response from Repo Assist.

Regenerating .SRCINFO before showing the diff would make the metadata comparison possible, but it would not make that validation safe: makepkg --printsrcinfo must evaluate the PKGBUILD, so a malicious PKGBUILD could run before the user reviews the changes. Diffing first does not help if the regenerated result is what must be produced before the diff.

That is why the current path treats the committed .SRCINFO as untrusted-but-parseable metadata and excludes it from the PKGBUILD Git diff; the actual build remains the point where makepkg executes the PKGBUILD. A verification mode could still be useful as an explicit opt-in after download, clearly warning that it executes the PKGBUILD and comparing the generated metadata afterward. It could also help close #2888 if maintainers want that trust trade-off, but it should not silently replace the existing metadata path.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@1c6668b751c51af8571f01204ceffb19362e0f66

[pricklythorn]

Why must .SRCINFO be regenerated before the PKGBUILD is diffed? Is diffing the package as the first step not feasible?