GPG Key Signing in Bitbucket

pnelsonsr

I've headed down the GPG Key signing in git road.  I've done all the Linux side of the creation of the key and have followed the Atlassian documentation of adding my key to my Bitbucket Server account. I say right off the bat I have not signed a commit yet or have I done a pull request yes as I really don't understand the Key environment enough.  I have a couple of questions that I have exhausted my searching for answers.  I hope someone can enlighten me, so here are my questions:

1 I've been trying to understand how Bitbucket deals with signed keys and if the fact that I have an integration with JIRA also changes anything.  The docs I have found tells me how to set it up but not what it gives me.

2  I do all my merges in Bitbucket through Pull Requests.  How does this work with GPG Keys?   

pmqs

My interpretation of 'what you get'  with GPG signing is identity validation for SCM commits. Or to put another way, I see it as a kind of 'personal digital signature' for your SCM process, see here: https://confluence.atlassian.com/bitbucketserver/using-gpg-keys-913477014.html

By signing your commits with your GPG key, and of course, assuming the privacy of such a key, there can be no question of 'who made that commit' as it's basically 'digitally signed'. To the best of my knowledge, even if I retrieved someone else's GPG key, assuming it was already assigned to a user in Bitbucket, I don't *think* I would be able to add it to my account as well but I can't say for sure.

Also, this would really be local to whatever Bitbucket server you set it up on, vs something like Git, where my understanding is, the GPG key could be guaranteed as unique across the whole of github due to its centralised user base.

Overall, I see it as a 'security blanket', or perhaps as a 'verification of identity enhancement' for SCM commits - maybe for compliance/auditing etc

I'm not totally sure how/if this feeds into PR's as such, but if you use GPG signing, the commits that make up any given PR will be signed by the user(s) that made them.

The process shouldn't change overall, except for devs who need to configure automatic GPG signing when doing a push locally (i.e. local git client for every dev needs to automatically GPG sign). Though if 1 dev didn't configure their GPG signing, unless you can restrict pushing to the repo with no GPG key, the main difference is, that 1 dev's commits won't be 'verified'.

I can't say with any complete certainty regarding Jira integration, but I don't see that anything here would be changing. In most SCM systems you get a shiny badge that shows the commit was signed, maybe this badge pops up in Jira as well.

As mentioned earlier, I don't believe GPG signing is a functional change, but more of an extra 'security layer' on your existing SCM processes and from where I'm sitting, its primary function is to validate the person listed on any particular commit in SCM is 'actually that person' and not some imposter.

Apologies if this doesn't help with your questions or that it's 2 years late, but hopefully you understand it might not really give you anything more than a little more peace of mind and perhaps a shiny green tick from the auditors.

It is with some irony that I found this post looking for GPG configuration in bitbucket and it seems like it's still not supported in their Cloud version. Given the feature request for this was created in 2011, it appears Atlassian have scant regard for such security enhancements common to most other SCM products in their Cloud SCM platform (Bitbucket) (https://jira.atlassian.com/browse/BCLOUD-3166)