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 Process for reporting security issues jamuluswebsite#319 (comment) 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.

[ann0see]

I am still confused. When I created the first key according to your step-by-step guide, I exported a private key and uploaded it to Github.

Yes that's correct. But I believe the key is still stored in the GPG keychain - I think that's the case for me at least. So you probably still have a copy. I'd still create a new key.
It's my fault that I said you need to provide a password. GitHub actions can't decrypt the password protected key ofc and adding a password is probably not adding more security.

Ah, so does it mean the secure area of Github where I uploaded the private key is only accessible by myself and no one else? That would then make sense.

Yes. I think you can't even read it after you've added the content - only overwrite it.

However, GitHub actions can read it (of course this means that if the runner is compromised, the key and all other secrets like the SSH key hoffie added could be stolen).

[corrados]

Ok, I have created a new key without a password and updated the secret "GPG_PRIVATE_KEY" with the new key.

[ann0see]

Great! Thank you very much. I'll update the nightly.

[ann0see]

I've now also added a GPG key to my GitHub profile.

[ann0see]

@pljones what is outstanding here for 3.10.0? The macOS stuff? I think it's too late for today.

[pljones]

It wasn't marked as done, so I assumed there was something not done that needed to be done for 3.10.0. I don't know what.

[ann0see]

No. MacOS self signing is not blocking.

[pljones]

OK, so can this be closed under 3.10.0?

[ann0see]

If every main dev has a key in their profile, probably yes?

[ann0see]

Also SECURITY.md needs to be updated

[softins]

If every main dev has a key in their profile, probably yes?

I don't. It's not clear to me what I should do to make one and what I would use it for. I will review the conversation above, but a brief summary would be useful.

[ann0see]

@softins if you use Gnome on a Linux machine, you can generate one via a GUI. I think it's named Paasword or Keychain?

[pljones]

Are we going to go anywhere at all with this, or should the issue just be closed? (It's been open over three years and gone nowhere.)

[gilgongo]

Are we going to go anywhere at all with this, or should the issue just be closed? (It's been open over three years and gone nowhere.)

We do at least have our public keys in our GH profiles somewhere (see my GH profile), so in theory somebody could send one or all of us a secure message with that (and @softins as I think you asked about this?).

I lost track of the more ambitious plan to generate a key for team@ though. Seems rather complicated.

[ann0see]

I can update my key on my profile (It may have expired). But it shouldn't be a problem for at least all of us having one in our profile.
Then not have a shared GPG key, but tell users/reporters to send a message to the team mail and maybe tell that an encrypted email is incoming. Then send the encrypted email to each person individually.

[gilgongo]

That would work, although one thing that occurs to me is that we could have, say, "[email protected]" which encrypted the mail to all our keys, then forwarded that to team@ perhaps (I'd need to give the mail account our public keys of course, and keep them up to date, but after that I think a procmail recipe could run gpg with formail). I could try and see if that works?

[pljones]

Wouldn't it be easier to follow if

• there was a security-reports@ key pair
• people sent encrypted to security-reports@ with the published security-reports@ public key
• security-reports@ had our public keys and forwarded securely using them

That way team@ doesn't get involved for secure communications, which could cut down unintentionally sending insecure messages.

[gilgongo]

Ah OK so senders just need to have the security-reports@ public key and don't need to find ours. Would be easier, yes. It would need its own key pair to encrypt to our keys in any case. But it would it need to add our keys to their encrypted message, no? Not sure how PGP does that, but I suppose it's possible (could decrypt on the server then immediately re-encrypt to us maybe?).

Can't prevent people sending encrypted to team@ though of course. But I could try gold-plating things with a header sniffer that rejects encrypted emails (with a message) and vice versa for security-reports@ maybe :-)

[ann0see]

Decrypting on some server sounds bad practice!

[pljones]

Sharing a private key sounds pretty bad practice, too. Those are the only two ways of doing it, though.

If you make the { decrypt -> re-encrypt } flow secure, then the clear text should never be available. I'd hope the gpg toolset has a "decrypt with this key and re-encrypt with that key" command and can do it securely.

[gilgongo]

This turns out to be rather more difficult than expected, and not only because incoming mail could be ASCII in the body, PGP-MIMEed, or as an attachment (binary or ASCII). I've got it to forward plaintext emails to me encrypted at least, but that breaks DKIM and any DMARC stuff, so Gmail puts it into spam :-(

How's best to progress on this? Shall I do a PR with what I've got or something? I'm adapting a script here.

EDIT: Just found this will keep fiddling.