ci: signed commits

[sparten11740]

Our branch protection rules require us to use signed commits. This adds changes the committer to the bot that creates the PR and enables GPG signing

• Depends on feat: allow different committer than assignee lerna-release-action#48
• Create a release env and add GPG_PRIVATE_KEY and GPG_PASSPHRASE as secrets

Testplan

Tested in https://github.com/ExodusMovement/lerna-version-selectively/pull/504

[mvayngrib]

@633kh4ck could u have a look at this?

[sparten11740]

I gave this a review and I can't see any malicious attempts at trying to steal the keys. Note that I didn't review the openpgp package which has access to the private key here: https://github.com/crazy-max/ghaction-import-gpg/blob/60f6f3e9a98263cc2c51ebe1f9babe82ded3f0ba/src/openpgp.ts#L18-L20

[sparten11740]

good to merge for now? the consequence of that GPG key leaking wouldn't be dramatic imo

[mvayngrib]

ping @633kh4ck

[ChALkeR]

why do we need a thirdparty action for this / why can't this be a command?

[mvayngrib]

ping @633kh4ck

[sparten11740]

we can stop using the 3rd party action and go for a vanilla approach instead such as

      - name: Configure GPG Key
        run: | 
          echo -n "${{ secrets. GPG_PRIVATE_KEY }}" | base64 --decode | gpg --import
          git config --global user.signingkey ABCD1234

[633kh4ck]

we can stop using the 3rd party action and go for a vanilla approach instead such as

It looks safer and cleaner at first glance (or we need to audit third-party code, including openpgp package). However, we would also need to implement passphrase support (see https://github.com/hashicorp/ghaction-import-gpg/blob/2c0efc4138244c5ffcc48520962918bf8a166eee/action.yml and https://gist.github.com/vansergen/88eb7e71fea2e3bdaf6aa3e752371eb7 for a general idea) and cleanup stage (https://github.com/crazy-max/ghaction-import-gpg/blob/1a317071222a9bfb1839df1b58b1f0dcd893b589/src/main.ts#L134-L148).

[github-actions]

Houston, this is Conflict Bot. We have a conflict. I repeat, we have a conflict. @sparten11740 please rebase. Acknowledge.

[ChALkeR]

Another way would be to use GH API to generate commits instead, which is what other gh actions do

Then we won't have to sign them manually at all

[ChALkeR]

Single-file updates: https://docs.github.com/en/rest/repos/contents#create-or-update-file-contents (you also want branch and sha options)
This should work nicely

Fine-grained API which can build a commit with changes across multiple files: https://docs.github.com/en/rest/git/commits#create-a-commit
Not entirely sure if this one works to make the same kind of API verified commits

[mvayngrib]

@marcoskichel we currently use git here but looks like we can use the GH API to get signed commits. Could you have a look when you have time?

[sparten11740]

Changing the files through the API has two disadvantages:

it's subject to API rate limits (not a big deal if we only do it in this repo) and which is more annoying: we need to be explicit as to what files need updating. In this case all package.json's and changelogs of the released packages and potentially the lockfile. I find the git cli with signed commits more appealing tbh

[mvayngrib]

@sparten11740 does this PR need to be updated to use https://github.com/ExodusMovement/git-signing-action ?

[sparten11740]

Yes, but we first have to make the action repo public. Any objections?

[mvayngrib]

just asked on Slack in #ossing-requests