Start publishing signature files for binaryen artifacts

[liutikas]

Request

Start publishing armored signature files for binaryen artifacts. E.g. for binaryen-version_118-aarch64-linux.tar.gz add binaryen-version_118-aarch64-linux.tar.gz.asc file so that the origin of this artchives can be validated.

Reasoning

Today releases for binaryen ship as tar.gz archives (e.g. binaryen-version_118-aarch64-linux.tar.gz). Kotlin Gradle Plugin uses binaryen for javascript multiplatform targets. It fetches these files from https://github.com/WebAssembly/binaryen/releases/download. Sadly, users that use Gradle signature verification have to allowlist binaryen artifacts because they are missing .asc signature files. Validating signatures allow consumers of binaryen to know they are getting artifacts from an expected source.

[liutikas]

Here is an example of how users can currently allowlist it in their gradle/verification-metadata.xml

<?xml version="1.0" encoding="UTF-8"?>
<verification-metadata xmlns="https://schema.gradle.org/dependency-verification" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://schema.gradle.org/dependency-verification https://schema.gradle.org/dependency-verification/dependency-verification-1.3.xsd">
   <components>
      <component group="com.github.webassembly" name="binaryen" version="117">
         <artifact name="binaryen-117-x86_64-linux.tar.gz">
            <sha256 value="3dc677006555b355ea2da5e82602065a161d5e83eaefd3f759afa00b96e83212" origin="Generated by Gradle" reason="https://github.com/WebAssembly/binaryen/issues/6783"/>
         </artifact>
      </component>
   </components>
</verification-metadata>

[kripken]

I'm not familiar with this but it sounds like a good idea. A PR to add it to our releases would be very welcome.

[liutikas]

I am sadly not a cmake expert, but what you'll want is create a pair of PGP keys (private and public one that get published to keyservers like https://keyserver.ubuntu.com/), then use that key to generate .asc files for the artifacts that already get created by your cmake build.

cmake really just needs to call gpg with the private key and the artifact tar.gz as arguments and write that out to .asc file.

https://github.com/scivision/cmake-gpg-sign

[mtb0x1]

cmake really just needs to call gpg with the private key and the artifact tar.gz as arguments and write that out to .asc file.

The thing here is you need to make sure the private key stays private, so one way is to create a new repo secret and use it. I am not a fan of this one, There is a risk of intended leaks and you need to watch out for dodgy commit around it.

Another way is to move the release ci to private infrastructure and ~eliminate~ reduce risks. (costly and defies transparency/opensource purpose)

[liutikas]

What's used for release ci today? If it is GitHub actions, it already supports secrets and it filters them out from all the build logs if there is an accident leak.

Signing has a high value to be able to know the binaries have not been altered in transit.

[kripken]

What's used for release ci today?

GitHub actions, yes:

https://github.com/WebAssembly/binaryen/blob/main/.github/workflows/create_release.yml

[liutikas]

Then adding a github secret and using that for signing should be fairly straight forward https://josh-ops.com/posts/storing-certificates-as-github-secrets/

[liutikas]

Any updates here? We'd really like to see this.

[kripken]

I'm not aware of any work on this. I could find the time to look into the secrets part, but first it would be good to see a PR that does everything aside from that (as I have no idea where to begin there).