Security: Generate and document GPG key(s)

[hoffie]

Has this feature been discussed and generally agreed?

jamulussoftware/jamuluswebsite#319 was about documenting the process and a contact address for reporting security issues. It was also discussed to provide a way to contact the project in encrypted form. This still needs to be done.

I'm opening this on the code repo as this is where SECURITY.md lives and will have to be updated.

Describe the solution you'd like

Variants:

1. Document each developer's own GPG key (and address) on their team page (tbd)
2. Generate a key for team@ and share it. Both variants have advantages and disadvantages, see https://github.com/jamulussoftware/jamuluswebsite/issues/319#issuecomment-803663521 and later comments.

[gene96817]

2. Generate a key for team and share it.

Sharing a key is generally considered a bad idea. If one member is compromised, the key has to be revoked for everyone. With individual keys, each member is accountable and when compromised, only one member is affected. In addition, if a member leaves the project, nothing special needs to be done. One of the benefits of GPG is that every message is signed and only the owner can sign the message.

[DominikSchaller]

I think you linked the wrong issue. 319 is about ukulele.

[gilgongo]

In theory, I think we could automatically encrypt all incoming mail to the team address to each Jamulus maintainers' key. Would that help?

[gene96817]

That is the idea. In this way, you always know:

• who sent the email,
• you can verify the email was not modified

[gilgongo]

Well, you'd at least know it was was from the mail server for jamulus.io. Senders could also be confident that any reply had been read by the intended recipient, and if the recipient signed their reply the sender could check the fingerprint with the one on the website maybe?

[gene96817]

Many years ago, checking the fingerprint was a tedious, manual process. Assuming you are using a mail reader that supports GPG (e.g. Outlook, Apple Mail), you would import the correspondent's public key. The mail reader does all the work. It can handle (1) encrypted mail or (2) signed mail (meaning the mail is in plaintext and it includes a signature to verity the mail has not been modified en route).

I don't know how many mail readers support GPG. I suggest you try using GPG for a few days. It is really convenient (compared to some 15+ years ago).

[gene96817]

I said it backwards. I don't know how may GPG plug-ins there are for mail readers.

[ann0see]

The GPG issue comes up again if we provide a .deb PPA.

[gilgongo]

In both cases, the problem to solve is that of having a single Jamulus Project signature/fingerprint, but with one or more signing keys so that we avoid having to share a private key in some way. Is that right? I know that multiple keys can sign a single file, but then verification has to be done against the key(s) of whoever signs. Wonder how Debian does it?

EDIT: Are subkeys the way to do this? https://github.com/foundriesio/gpg-key-signing

[ann0see]

I think sharing the private (master) key would be the problem.

Some maindev could also create a private master key sign our GPG keys and then delete the private master key...

This would mean that we can never sign new keys.

Debian: https://wiki.debian.org/Keysigning

[gilgongo]

This would mean that we can never sign new keys.

Although that's not necessarily a problem as new keys would be a very rare occurrence. Or have I misunderstood?

[ann0see]

True. But it's an inconvenience

[gilgongo]

Actually, reading this I think that might not be so bad:

https://mikeross.xyz/create-gpg-key-pair-with-subkeys/

We'd probably need to set the key to expire about once every couple of years anyway. But subkeys mean the master secret key can be kept offline.

[ann0see]

Ok. Do we have a consent here who stores the master key? I'd go with Volker if he wants to – as he's a neutral person.

[ann0see]

@jamulussoftware/maindevelopers both the macOS and debian signing PRs are now in. How do we continue here? I can of course create both, but is this OK? Probably, we'd go with a CA approach?

[pljones]

I'd rather find a CA we can agree on and all have access to.

[ann0see]

So you'd want a commercial CA?

[pljones]

Or https://letsencrypt.org/ might be a free option. Or http://www.cacert.org/. Or https://www.buypass.com/products/tls-ssl-certificates/go-ssl .

This might be useful. The site references various CAs issuing free certificates. https://scotthelme.co.uk/certificate-authority-authorization

[ann0see]

At least let's encrypt is domain verification. CA cert looks interesting, but I'm not sure if I'd really trust them.

[ann0see]

@corrados Would you be willing to create a Certificate Authority as "center of trust" for the project?

I think it would work as follows:

1. Volker creates a CA certificate
2. The Jamulus team sends their GPG keys or a Certificate signing request (think that's a CSR) to you which you sign
3. Someone creates a certificate for the debian repository which gets signed by the CA or a sub certificate
4. We deploy the GPG key for the repo

I think Volker as "neutral" party should have the "highest" certificate as he's the initial founder people must trust anyway and saves the certificate.

He could then even sign a CA the team uses for production so that he's just a high level backup and source of trust if the team looses a certificate (this of course brings the problem of private key sharing).

I'm not too much into Cryptography, but I think this should work.

[ann0see]

The problem with a commercial CA is that they're mostly verifying domain names - I think.

[corrados]

Would you be willing to create a Certificate Authority as "center of trust" for the project?

Yes, I can do it. But you have to tell me exactly how to do it since I have never done this and I do not want to make mistakes...

I think Volker as "neutral" party should have the "highest" certificate as he's the initial founder people must trust anyway and saves the certificate.

That honors me :-).

[ann0see]

Thanks! I will try to find or write a step by step guide.

I think the easiest way would be a Linux machine. Do you have access to one?

[corrados]

Yes, I have access to a Linux PC.

[ann0see]

After some research, I think what we are planning is not standard for GPG keys: https://unix.stackexchange.com/questions/401577/gpg-trust-like-an-ca-cert

macOS could use this approach - but it's not that important there as it would only be for non release builds.

So I'd suggest the following for the

Debian repository Key (Fixes: https://github.com/jamulussoftware/repos/issues/1)

1. Volker generates a GPG key https://www.redhat.com/sysadmin/creating-gpg-keypairs and stores it somewhere securely. The E-Mail needs to be determined, but is probably the standard one (@pljones what do you think?). I'd suggest RSA 4096 bits long. If we can verify that ECDSA (more modern cryptography) works well with apt, we can also upgrade.
2. Volker adds the GPG key as repository secret (we'd need to give him access to the repo, but that's no problem. If he wants, he can remove himself later on)

This means that the key isn't shared.

Concerning a key for the e-mail communication

we could use the same key, but I don't think that's the solution. I think that each maintainer should publish his (public) GPG key to e.g. his Github profile. We wouldn't have a shared key for the E-Mail address, but if something encrypted gets sent to it, the respective maintainer should forward the message to other developers.

(unrelated) Concerning signing pre-release builds with a self signed certificate for macOS

we could use the CA approach, which I hoped would also work for the GPG keys. Someone, maybe Volker (?) would generate the CA on a Mac and sign certificate/s we'd then add to the CI

• I think the Debian key creation is actionable and needs an OK from @corrados and @pljones
• The macOS CA creation is also actionable
• The E-Mail question still remains open

What do you think?

[pljones]

I think the Debian key creation is actionable and needs an OK from @corrados and @pljones

OK by me.

[ann0see]

Ok. Great. Then I'll provide a step by step guide here:

Creation of GPG key for Debian Repo:

1. On a linux machine, in terminal run gpg --full-generate-key
2. Select RSA and RSA (1)
3. Select a RSA keylength of 4096 bit
4. Select a expration date of 3y - I believe that's ok
5. Confirm that the information is correct by typing y
6. As name provide The Jamulus Development Team
7. As E-Mail provide the E-Mail from here: https://github.com/jamulussoftware/jamulus/blob/main/SECURITY.md not pasted here for anti spam reasons
8. As Comment provide: GPG key for signing Jamulus releases generated by the official deb repository
9. Confirm
10. Provide a secure password (this should not be published)
11. Export the private key by executing gpg --export-secret-keys -a -o jamulus_test.asc [id] The id is a long Hex number.
12. Add the content of the exported file to https://github.com/jamulussoftware/jamulus/settings/secrets/actions repository secrets. It should be named GPG_PRIVATE_KEY: https://github.com/jamulussoftware/jamulus/blob/1736d2ad7276db575762f8e4d6f23fd32428f9b9/.github/workflows/autobuild.yml#L446
13. Kick off a beta build

[ann0see]

I've invited @corrados to the organisation, so he should have enough permissions to add the secret.

[pljones]

10. Provide a secure password (this should not be published)

But make sure it's not lost..! :)

[corrados]

Ok, I've done it. What I have not yet understood is if I need to store anything else but the secure password. But I guess this is not the case since I added the private key to the Jamulus repo secrets and this should contain all the necessary information, right?