Set up release infrastructure

[djspiewak]

This is where we're going to need help from @gzm0 and/or @sjrd. I'm assuming you want to do CI releases? I'm cool either way. Feel free to futz with the infrastructure as much as you like.

[gzm0]

I'm assuming you want to do CI releases?

Yes. I guess you can take https://github.com/scala-js/scala-js-dom as an example.

You'll have to ask @sjrd to setup the keys for you.

[sjrd]

I have set up all the require keys in the GitHub Secrets, as explained at https://github.com/olafurpg/sbt-ci-release#secrets, like I did for scalajs-dom.

[djspiewak]

@sjrd Does that include the PGP_PASSPHRASE? I ask because that particular configuration is incompatible with sbt-gpg and adds no actual security in this scenario (since the key is already encrypted). I can work around it in the build, it's just moderately annoying. (note that sbt-pgp, which is compatible with the PGP_PASSPHRASE approach, is only able to maintain that compatibility by using GPG incorrectly and in a less secure mode which is in turn incompatible with some more advanced approaches to key management)

[sjrd]

Er, yes, it includes PGP_PASSPHRASE. I am blindly following sbt-ci-release's readme, as I have no other reliable source of information on this topic. If I should do something differently, please tell me what or point me to some alternative docs.

[armanbilge]

@sjrd See sbt-spiewak.

[sjrd]

OK, so I should just delete the GitHub Secret for PGP_PASSPHRASE? Is that enough?

The linked doc says

You can obtain the PGP_SECRET by running gpg --export-secret-keys | base64. Please make sure that this key is not password protected in the export (GitHub Actions itself will encrypt it).

How do I make sure that the export is not password-protected?

[djspiewak]

This bit is slightly tricky. Like I said, we can work around it in the CI script if it's too much of a pain. :-)

What you need to do is edit the key in your gpg keyring to remove the password, and then do the export. gpg --edit-key <keyid>, then run passwd and just hit Enter twice. This strips the key of its internal encryption, after which you can export it. Obviously you shouldn't be doing this with your personal GPG key, and rather with a specific CI release key (ideally specific to just this repository) which you then sign with your personal key.

The more nuanced argument here is the fact that the gpg password is normally used to encrypt the key at rest. GitHub Actions is already encrypting the key at rest, which is why the second layer of encryption doesn't add any security.

[sjrd]

Huh. I'll see if I can sort this out. Thanks for the explanation.

[djspiewak]

It's alright if it's too much of a pain. :-) Like I said, we can work around it in the CI script. Just figured I'd push on it a bit because there are a lot of misconceptions around this space (including in the sbt-ci-release documentation!) and I'm trying to nudge the community in the right direction a little bit at a time.

[djspiewak]

I think I got the release infra working. We'll find out! It would still be very helpful if I could remove the current pinentry hack to work around the double-encrypted signing key.