Generate GPG signature for commit when edit a file in web editor
Description
Generate GPG signature for commit when edit a file in web editor.
Overview
When I edit a file in web editor and make a commit or accept a merge request, this commit isn't signed. Maybe add an option for new GPG key generation for the user. After it, these commits are signed with the GitLab generated key.
Use cases
- Edit file in web editor
- Accept merge request
Activity
added Platform ~65372 feature proposal gpg labels
GitLab generate a new keypair (with key password) for the user.
In that case you would still have a private key stored on the server so that anybody with access to the server can sign commits in your name. For me that defeats the purpose of GPG signing.
Adding a password to the key makes it harder to steal the key. However usually the private key has much higher entropy than the password.
/cc @briann ?
I could kinda see the benefit for locked down instances where developers aren't allowed to install GnuPG on their workstations... but it's a very limited use case. And as @winh said, anyone with access to the server would be able to sign commits as anyone else (even if it involved sniffing the passphrase when commits were pushed). And how would you pass the passphrase to GitLab on each push?
I certainly wouldn't want this option enabled on any GitLab instance I ran.
I think this would really only be useful for commits that leave GitLab. While it's on GitLab, you can find who committed it, at least to the extent your GitLab server is secure. The same as if you stored a private key on the GitLab server. Once it leaves GitLab though, there is no way to tell unless its signed.
To try and achieve higher security, you could keep the keys client-side using https://openpgpjs.org/ but that doesn't really provide much of a security advantage, AFAIK. Someone with control over your GitLab instance could just change the JavaScript being served to the client, and make it do nefarious things (like upload the private key).
You could probably get the security to an acceptable level by serving the OpenPGP JS from its own domain (and thus different origin), so JS served from your GitLab instance couldn't get to the key. And then that other domain is serving only static content, so it can be very tightly locked down... Doesn't seem like much of a general-use feature, though.
duplicate of https://gitlab.com/gitlab-org/gitlab-ce/issues/36619
