Have Gitpod-based commits GPG-signed

[sr229]

There are some projects that requires commits to be GPG-signed to verify the authenticity of a contributor. Gitpod should be able make commits GPG-signed as a preference or automatically like browser-editing.

[libbitc]

Hi,

If home directories were persistent (see #340) then gpg keys may be imported into a persistent home area./home/gitpod/.gnupg/ or /home/<github username>/.gnupg/

[jankeromnes]

If home directories were persistent (see #340) then gpg keys may be imported into a persistent home area./home/gitpod/.gnupg/ or /home/<github username>/.gnupg/

Good suggestion, thanks!

But since persisting the home directory seems a bit complicated, I have found a potential work-around (that I'd like to use for SSH keys):

1. Set SSH_PUBLIC_KEY and SSH_PRIVATE_KEY environment variables in https://gitpod.io/environment-variables/ (you may restrict this to repos you trust, e.g. yourname/*)
2. Add something like this to your projects' .gitpod.yml:

tasks:
  - before: >
      mkdir -p ~/.ssh &&
      echo $SSH_PUBLIC_KEY > ~/.ssh/id_rsa.pub &&
      chmod 644 ~/.ssh/id_rsa.pub &&
      echo $SSH_PRIVATE_KEY > ~/.ssh/id_rsa &&
      chmod 600 ~/.ssh/id_rsa

This will re-setup your SSH keys automatically in every workspace for that project, and may be adapted for GPG keys too.

It's a bit cumbersome, because it requires a project configuration change, but may work. I wonder if SSH and GPG could also accept keys as environment variables, removing the need for creating special files in the home directory.

[libbitc]

Hi,

The following would work for GPG keys so something similar will also work for .ssh.

1. Convert your source .gnugpg directory contents to base64 data:
   tar -czvf - ./.gnupg | base64 -w 0

2. Place this data into a gitpod environment varaiable called GNUGPG

3. Add following to project's .gitpod.yml:

tasks:
  - before: >
      [[ ! -z $GNUGPG  ]] &&
      cd ~ &&
      rm -rf .gnupg &&
      echo $GNUGPG | base64 -d | tar --no-same-owner -xzvf -

[jankeromnes]

Thanks for the tip!

2. Place this data into a gitpod environment varaiable called GNUGPG

You can even do this directly from a Gitpod Terminal, like so:

gp env GNUGPG=$(tar -czvf - ~/.gnupg | base64 -w 0)

[corneliusludmann]

I don't like to store my private GPG (or SSH) keys in a (unencrypted) third-party database (aka “not my computer”), but I really would like to sign my commits. I think one should rather use a secure solution like Krypton for that (see also #782, thx @Vlaaaaaaad for the hint). With Krypton, the private key never leaves the security chip on your phone.

We could add Krypton to the Gitpod base image gitpod/workspace-full. I was curious how well Krypton works in Gitpod. Thus, I created a simple sample repository (with some notes in the README.md): https://github.com/corneliusludmann/gitpod-krypton-example You still need to pair (kr pair + scan QR code with your phone) and enable (kr codesign) Krypton in every workspace via the terminal. (It's totally fine for me, however, it shouldn't be to hard to build a plugin/widget for GUI support for this.)

Pros of adding Krypton to the Gitpod base image:

• Having a secure (!) way to sign your commits.
• Little effort to support signed commits in Gitpod.
• Could encourage users to sign their commits.

Cons of adding Krypton to the Gitpod base image:

• Additional dependency in the base image for a feature that may not be used by many people.
• Feature is “hidden” behind the terminal. A proper documentation on the Gitpod website could help users to discover this useful feature. Or even a widget.

How do you feel about it? Any opinions?

(Probably there are even alternatives to Krypton?!?)

[Vlaaaaaaad]

I very much like the idea( it's what I use now due to me switching tons of devices for work) and it also adds secure SSH for people who need that buuuuut krypt.co has been acquired and is now a part of Akamai. No comment has been made regarding the future of krypt.co so I would be against adding it in the base image until the future of the project is known.

CC @kcking and @agrinman for a comment on this.

[libbitc]

I don't like to store my private GPG (or SSH) keys in a (unencrypted) third-party database (aka “not my computer”),

@corneliusludmann If the keys are password protected then they are encrypted .

[corneliusludmann]

If the keys are password protected then they are encrypted .

You're right. That makes it much better. The only thing left is that you have to decrypt the keys in the (probably “untrusted”) workspace to sign your commits, don't you? It's still a (small) attack vector that services like Krypton solve.

[sr229]

I would prefer much to have an option to have Gitpod generate a one-time GPG key for me just like GitHub were they provide a GPG key for each account when you perform a browser-based edit as well.

There's reasons why this would be feasible since not everyone likes to provide their own keys and would probably prefer to have a service generate it for them.

[sr229]

while the solutions you have might be good, again, in my opinion, this increases complexity if we wanted Gitpod to be just a out of the box experience, meaning user should just code and test, and that's it. I think this should be a optional integration for services like Krypton since I don't feel like its worth the configuration for many just to have their commits authenticated. Having options is a nice little thing.

[JesterOrNot]

I agree with @sr229 the idea of the service is "frictionless coding" I feel it would compromise the goal of the project to force this it should be recommended but not forced upon users.