I feel this is a very fundamental requirement, which should be given a higher priority. Many git users are now signing their commits. It's impossible to view the commit log on BB and is a major decisive factor when choosing between BB or github (and i want to favor BB). Hopefully, this will be resolved soon.
Ryan Winchester I believe Linus meaning with that statement is considering the goal of verifying the integrity of the entire project. I believe a very legitimate use case for signing individual commits is verifying the authorship of a single commit. For example, if I merge in a PR from a co-worker, and tag, then my stamp of approval is on the state up to that tag. But what if my co-worker (or someone with access to their machine) maliciously made a commit with my name and email, and I don't see it? Well I've placed my stamp of approval on the whole darn thing. You can say, "Well, be more careful next time!" Or, if each of my commits are automatically signed while on my machine, and I maintain reasonable security of my machine, then I can at least say "either someone else is impersonating me, or I intentionally didn't sign that commit to trick you all". So... not totally stupid, in my humble opinion.
We sign individual commits - it ensures the we know how each piece of code got into the stream - a specific known individual put it there. Unless you tag each commit (clearly absurd) you can have code in the stream which isn't vouched for. Now, certainly if I sign a tag you can argue I am vouching for the full history of the stream (including all child commits) up to the tag. But this isn't realistic - there's no way a single individual is going to fully review a huge code base and every commit leading to it. For us this provides a level of security that we know the code stream hasn't been hacked. http://mikegerwitz.com/papers/git-horror-story.html provides nice bedtime reading that I find more convincing than Linus' posts.
Right, that is the greatness of open source.
The system can became better that the creator would make it.
Git is being used in many ways that Linus would not use it, probably like teams.
In the flow of work that him uses is probably unnecessary and idiotic to use signed commits, but in the flow of many of us is indeed necessary.
One example is that developers get angry at work, they may want to get back at some coworker or their chief or a client and they may try to undermine the code and not leave a trail.
The simple case that Git does allow you to impersonate someone else when doing a commit it is a huge security risk, but it is like that because is a non centralized system (probably Linus also thinks Github or Bitbucket are unnecessary).
In that context being able to secure a way to know the commit was indeed made by the person it says it did it, its a required feature in my opinion.
I love Bitbucket and I use it every day, but I think it would make it a lot stronger to support signed commits. :)
In open source, every single commit has to be in-depth checked for legitimacy, correctness and style anyway, and then they can be collected into a tag and signed by the responsible. So Linus saying that commits need not be signed is perfectly understandable. However nobody is going to pay a software development company to do that. (if its not for high-risk software like say aerospace, banking, etc.)
But it does make sense to establish the origin of a commit in a company, so you can quickly wave a red flag if the committer and the signature do not match, or simply reject any commits where something like this happens (and notify ops).
This easily catches cases where a developer just copies the config file from another and commits code with their name, or where they use their private config or config from another company, etc. It's not hot when you ship the repository to a customer and something like "email@example.com" committed half the code.
The idea of supporting signed commits has certainly been bumping around our team for a while.
I hope the feature it's in your radar by now.
There are plenty of large enterprises out there who require engineers to digitally sign the commits they perform on the work they do. Having a visual reference here (and for those who integrate with Jira, there as well) would save some time to those required to verify a commit has been signed during code reviews, etc.
I don't want to make a raw complaint to Atlassian about this "minor" enhancement. Rather I'll post there a real scenario where we really miss this security feature (today I think we could't call it feature because many competitors already have it so it should be a core function) and it complicates are lives.
We are moving our business to cloud and had decided to purchase Atlassian tool set. As the security is essential for us we created a security architecture based on Atlassian tools (may be mistake now:)) and AWS where necessary. In short scenario looks like:
1. Developers have to sign each commit (they sign commit at local PC)
2. After a Pull request all commits are validated against trusted keys (we check code integrity)
3. and further....
In step 2 we supposed that all interaction will be in Bitbucket UI (review, approval, merging) - ouha - there is a "Merge" (merge commit) and because of this Issue #3166 we are unable to sign this merge commit so we cannot perform merging from Bitbucket UI. You can think OK just do a merge commit from your local PC but why? In our GIT flow a Pull request must contain only commits which couldn't cause a conflict during a merging so then reviewer is really a QA guy who performs review and then click Merge (advantage - reviewer doesn't have to have code at his/her PC, reviewer uses just Bitbucket UI wherever he is).
So what is a conclusion: Atlassian you have there a real scenario (business case) where this Issue #3166 makes your tool useless.