Proposal to Include .asc Signature Files in Ninja GitHub Releases

[Flavio Vincenzo Condemi]

Hi everyone

I’ve noticed that the current Ninja GitHub releases do not include .asc signature files for verifying the integrity and authenticity of the binaries. Adding these signature files would enhance security and provide users with a reliable way to validate downloads.

Would it be possible to consider including .asc signature files in future releases? I believe this would align well with best practices for open-source distribution and improve trust in the release process.

Releases · Kitware/ninja

Take a look at ccache release management:

Releases · ccache/ccache

I’d be happy to help with the implementation or provide more details if needed. Keep me posted.

Best regards,
Flavio Vincenzo Condemi

[Jan Niklas Hasse]

Hi Flavio,

What would be the point if you download the .asc file from the same source?

Best regards,

Jan Niklas

[Eli Schwartz]

On 1/19/26 12:15 PM, Jan Niklas Hasse wrote:
> Hi Flavio,
>
> What would be the point if you download the .asc file from the same source?
>
> Best regards,
> Jan Niklas

The point would be cryptographic code-signing -- consumers such as linux
distros could verify nobody has tampered with the releases (perhaps by
stealing an API token) and that the release is definitely the same one
the ninja maintainer's personal computer produced, signed, and uploaded.


--
Eli Schwartz

[Charles Nicholson]

Related, GitHub now has immutable releases, forbidding authors or adversaries from changing the contents of a release:

https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases

It would be nice for those to be turned on, for similar reasons.

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ninja-build/c2e87643-168a-4770-9682-0bca5d784ed2%40gmail.com.

[Eli Schwartz]

On 1/19/26 3:31 PM, Charles Nicholson wrote:
> Related, GitHub now has immutable releases, forbidding authors or
> adversaries from changing the contents of a release:
> https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases
>
> It would be nice for those to be turned on, for similar reasons.

Note this still cannot protect against an attacker creating new
releases, whereas new releases without historically used/documented
code-signing certificates would be a red flag.


--
Eli Schwartz

[Ben Boeckel]

On Mon, Jan 19, 2026 at 15:54:02 -0500, Eli Schwartz wrote:
> Note this still cannot protect against an attacker creating new
> releases, whereas new releases without historically used/documented
> code-signing certificates would be a red flag.

Is there not some mechanism PyPI and NPM(?) are using which use some
kind of authentication that GHA performed the actions that uploaded the
release (this at least forces the trojaned code to be pushed to the repo
in some way)? Is there a way to use that for GitHub releases at all?

--Ben

[Eli Schwartz]

Yes -- they use code signing via an OpenPGP alternative that uses
escrow, and then on top of that the entity performing the signature
would be GitHub, who sign that they on their end have confirmed "whoever
uploaded this package to PyPI possessed the ability to trigger GHA
workflows on push/tag, and therefore has permission to access PyPI
publishing tokens as well".

It provides no new information and as a downstream I simply would not
bother checking it. On the other hand, it's not worse than today, which
is also "nothing to validate". On the other other hand, this thread
proposes adding something...


--
Eli Schwartz