GPG signed commits

marked as a Work In Progress

changed title from [WIPGpg signed commits to [WIP] Gpg signed commits

marked the task Conform by the style guides as completed

Could someone UX please provide me with some suggestions / hints on how to style the badges in a nice way?

added 444 commits

cdc1c2ae...90040620 - 428 commits from branch gitlab-org:master
a6423a46 - Prototype key verification
56cff54b - remove commit actions width constraint
87fbd7c3 - commit signature with spec
6c16eccc - add gpg key model
73723fb0 - add emails method to GgpKey
0e8914c7 - only validate gpg_key#fingerprint "internally"
a003d210 - add profile gpg key page to manage gpg keys
12a8e8f7 - extract gpg functionality to lib class
ee271ed1 - add / remove gpg keys to / from system keychain
b6ca048e - add second gpg key for specs
16067684 - feature spec for gpg signed commits
24224930 - use example gpg key instead of my own
1248a6c5 - test with a gpg key with multiple emails
59e4503e - email handling for gpg keys
5bb73924 - move current keychain methods to namespace
97da3d87 - gpg email verification

Compare with previous version

marked the task Branch has no merge conflicts with master (if it does - rebase it please) as completed

marked the task Squashed related commits together as completed

added 5 commits

9daab061 - use example gpg key instead of my own
d70b4b9e - test with a gpg key with multiple emails
538573be - email handling for gpg keys
614d05b9 - move current keychain methods to namespace
ce00bf3f - gpg email verification

Compare with previous version

added 6 commits

9741e309 - feature spec for gpg signed commits
3c5fbdb2 - use example gpg key instead of my own
8de27210 - test with a gpg key with multiple emails
01aff262 - email handling for gpg keys
26d7514f - move current keychain methods to namespace
db1427e7 - gpg email verification

Compare with previous version

added ~164274 ~480950 ~18763 labels

Thanks @koffeinfrei! I'm trying to find the right person to review this. One question:

Currently the gpg keychain is stored in the rails process user's home directory. This means that the gpg verification works with all added keys within the same gitlab instance.

What happens if you have multiple servers running the Rails app, like we do on GitLab.com?

What happens if you have multiple servers running the Rails app, like we do on GitLab.com?

That's currently not working properly yet. I guess that SystemHooksService is the place for such behaviour isn't it? At least that's what the Key (i.e. ssh key) interacts with when adding and removing keys. Could you give me any pointers on how this works exactly?

added 14 commits

871d66b9 - add gpg key model
066d163d - add emails method to GgpKey
3f8ddf54 - only validate gpg_key#fingerprint "internally"
7911eb05 - add profile gpg key page to manage gpg keys
ff6c72d9 - extract gpg functionality to lib class
271764dc - add / remove gpg keys to / from system keychain
98544b9a - add second gpg key for specs
debaa96f - feature spec for gpg signed commits
9cfaea06 - use example gpg key instead of my own
7c47251c - test with a gpg key with multiple emails
3f1396ed - email handling for gpg keys
c3af7b91 - move current keychain methods to namespace
79a0e67d - gpg email verification
63b5b654 - notification email on add new gpg key

Compare with previous version

marked the task Notify user after adding a new gpg key as completed

marked the task remove keychain when user's email changes as completed

@koffeinfrei sorry about the slow progress on this one.

The file itself can go in shared storage: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/shared_files.md

My understanding (after getting a far more knowledgeable colleague to explain things to me) is that this keychain won't be written to often, once it has the most common intermediaries. Is that right?

At least that's what the Key (i.e. ssh key) interacts with when adding and removing keys. Could you give me any pointers on how this works exactly?

This system hook is used for integrations and also for GitLab Geo. It would be nice to add this hook, but I don't think it's required for Geo in this case.

This looks very nice, but I think that we should not use KeyChain.

We should parse signature in order to figure out the key fingerprint that we would look in the database.

The key verification to some extent should be cached, as this is a time-consuming operation.

We should be careful about date validity.

added 456 commits

806d3385...348dff0a - 437 commits from branch gitlab-org:master
8bfe6278 - Prototype key verification
19588e46 - remove commit actions width constraint
5a3bb9ab - commit signature with spec
4db37594 - add gpg key model
31836b0e - add emails method to GgpKey
d89b6c39 - only validate gpg_key#fingerprint "internally"
da6464b9 - add profile gpg key page to manage gpg keys
80a97d8c - extract gpg functionality to lib class
c0b9b3eb - add / remove gpg keys to / from system keychain
c0a981b7 - add second gpg key for specs
2e6ba6ed - feature spec for gpg signed commits
fbda179b - use example gpg key instead of my own
da601265 - test with a gpg key with multiple emails
bd3848f9 - email handling for gpg keys
50260622 - move current keychain methods to namespace
65b2c2e3 - gpg email verification
89d30f5c - notification email on add new gpg key
f6713667 - remove gpg from keychain when user's email changes
c4ed04c1 - fixup! add profile gpg key page to manage gpg keys

Compare with previous version

GPG signed commits

What does this MR do?

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Activity

GPG signed commits

What does this MR do?

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Merge request reports

Activity