Sign release with PGP

[cvgore]

Is there a chance to get signed releases, to verify authenticity of builds during automatic downloads?

It could be done this way:
https://github.com/yt-dlp/yt-dlp/blob/master/.github/workflows/build.yml#L514
https://github.com/yt-dlp/yt-dlp/blob/master/.github/workflows/build.yml#L557

[BtbN]

Hm, in theory that's possible.
But it'd mean a) that Github has access to the key signing it, and b) anyone in a position to upload releases to this repo likely also is in a position to access it from the Actions-Secrets.
So I'm not sure how much actual security it provides.

[cvgore]

via regular download flow - probably none, minimal :)
but as mentioned in first comment, it allows to verify authenticity of builds during automatic/unattended downloads.
let's imagine an app that uses ffmpeg as external dependency. to omit potential licensing issues, that app could be distributed w/o ffmpeg but can include helper tool that automatically fetches new ffmpeg version.

ad. b) aren't secrets hidden/masked after first set?

[BtbN]

They are hidden from the public, but obviously the actions can access them. How else would they sign stuff?
So if anyone would get access to the repo with the power to upload releases, they can also just run an action, and get the key and sign their artifacts with it.
Meaning as long as you verify the TLS certificate of github.com, the PGP signing would only add a minimal bit of additional work for a potential attacker.

[cvgore]

Meaning as long as you verify the TLS certificate of github.com, the PGP signing would only add a minimal bit of additional work for a potential attacker.

assuming the app has on its own public key embedded rather than downloaded each time, this eliminates public key swap chance.

here, Apache's Infra Team gives nice explanation why it's "nice to have" :)
https://infra.apache.org/release-signing.html#motivation

[BtbN]

It's different for official releases of software like apache.
They have locked away infrastructure, where only designated release managers have access. They verify and sign the tarballs.
That's much stronger than me uploading a private key to github, and having github then sign tarballs that are offered for download on github.

I'm more inclined to feel like that adding this kind of signing in this setup would result in a false sense of security, whereas the majority of possible attacks would just give the attacker the power to sign as well.
Like, the only time an attacker would not be able to sign stuff would be if they somehow gain the ability to upload releases, but can't run a Workflow.
Given I don't have ANY repository token generated, or tokens for my account or anything, that's a very unlikely scenario.

[cvgore]

ok, i get your point :) thank you for your time.

[BtbN]

I could have sworn I already have checksums somewhere, but it doesn't seem like it.
That might very much be worth adding.

[cvgore]

that might be also nice to have :) at least integrity could be verified of downloaded binary