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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.