3 ms·

you found the same one that i did while editing. if git is great, is it worth changing an enterprise to use it? when the auditors come, I need to list the chang

you found the same one that i did while editing. if git is great, is it worth changing an enterprise to use it? when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc. how granular and how far back can i get this with GIT? how solid is the nonrepudiation factor with GIT? for commits - can i see who else might be looking at code? for security - can i protect others from getting the code?

eru 13y ago
Does perforce provide cryptographic checksums? If not, git is actually a win as far as the auditors are concerned. git does not allow any changes to history. You can make new history and garbage-collect the old history. But for a fixed commit hash, all history and all contents are fixed forever. For extra security, you can sign the commits (ie their hashes) with your PGP key. > how solid is the nonrepudiation factor with GIT? Rock solid: as far as I can tell (from https://en.wikipedia.org/wiki/Perforce https://en.wikipedia.org/wiki/Perforce) in Perforce you have to trust your admin not to go behind your back and change history. In git you have cryptographic hashes to protect your history and content. > for security - can i protect others from getting the code? git leaves the protection to the file system permissions. git doesn't track who requested a change nor why. People usually do this via conventions in their commit messages. You can write plug-ins to enforce these conventions.
rallison 13y ago
You bring up some valid questions - thanks. I think you are getting at a few scenarios where, in fact, perforce is better. I like git, by no means is it the best solution for all cases. if git is great, is it worth changing an enterprise to use it? There are a ton of factors involved in answering that question. A lengthy blog post could be made trying to answer that. when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc. This depends on how git is setup. In the simple model of everyone on a team having push access to one origin server that serves as, effectively, the central repo, and that repo allows force pushes, then yes, this may not satisfy an auditor. As in, anyone on the team can rewrite history. Of course, when the central repo suddenly doesn't match up with all the copies everyone else has, somebody will probably realize that something is amiss. That said, being a DVCS, it is not hard to setup something where only a few top level people have push access to the what we'll call the authority server, and all commits from everyone else has to flow through these trusted people. Additionally, force pushing can be disabled on the authority server, so no one person can rewrite history (aside from the people who have direct file system access to the authority server). Or, think github - people fork a repo, then submit a pull request. Tons of people can commit to a repo, but most commits flow through a trusted few. how granular and how far back can i get this with GIT? If you are asking history, the git history goes back to the very first commit. It is also easy to list the entire history of just one file, and more. how solid is the nonrepudiation factor with GIT? As with a couple answers previous, it all depends on how git is deployed in the organization. The answer will vary from none to rather good, depending on the deployment. for commits - can i see who else might be looking at code? for security If you've granted access to someone to be able to pull from your repository, then no, you can't see who is looking at what. Anyone with pull access will have access to the entire repo. Want finer grained control here without resorting to multiple repositories? Then git is not the right vcs. This is where something like Perforce will win. can i protect others from getting the code? In what way? People who already have some access to the repo? See the above answer. Or Joe Q Public? That is trivial. -- Basically, the big area where something like Perforce (or even SVN I believe) will win is when you need fine grained control over security. E.g. User A only has access to this subfolder, User B only has access to this other subfolder, etc.
kderbe 13y ago
I have no experience with perforce so I cannot directly compare it to git. Some of the things you ask for can be done with git. As eru mentioned, you can sign a commit (and therefore all history leading to that commit), which will prevent anyone else from modifying its history undetected. With abundant signing and tagging, you could probably create a thorough audit trail. Git by itself does not have granular access control, and relies on filesystem permissions for security. The most common tool I know of to finely control write access to git (other than GitHub) is gitolite[0]. But even gitolite only provides read access control at the repository level. [0] What is gitolite? http://gitolite.com/gitolite/index.html#what http://gitolite.com/gitolite/index.html#what

eru 13y ago

Does perforce provide cryptographic checksums? If not, git is actually a win as far as the auditors are concerned. git does not allow any changes to history. You can make new history and garbage-collect the old history. But for a fixed commit hash, all history and all contents are fixed forever. For extra security, you can sign the commits (ie their hashes) with your PGP key. > how solid is the nonrepudiation factor with GIT? Rock solid: as far as I can tell (from https://en.wikipedia.org/wiki/Perforce https://en.wikipedia.org/wiki/Perforce) in Perforce you have to trust your admin not to go behind your back and change history. In git you have cryptographic hashes to protect your history and content. > for security - can i protect others from getting the code? git leaves the protection to the file system permissions. git doesn't track who requested a change nor why. People usually do this via conventions in their commit messages. You can write plug-ins to enforce these conventions.

rallison 13y ago

You bring up some valid questions - thanks. I think you are getting at a few scenarios where, in fact, perforce is better. I like git, by no means is it the best solution for all cases. if git is great, is it worth changing an enterprise to use it? There are a ton of factors involved in answering that question. A lengthy blog post could be made trying to answer that. when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc. This depends on how git is setup. In the simple model of everyone on a team having push access to one origin server that serves as, effectively, the central repo, and that repo allows force pushes, then yes, this may not satisfy an auditor. As in, anyone on the team can rewrite history. Of course, when the central repo suddenly doesn't match up with all the copies everyone else has, somebody will probably realize that something is amiss. That said, being a DVCS, it is not hard to setup something where only a few top level people have push access to the what we'll call the authority server, and all commits from everyone else has to flow through these trusted people. Additionally, force pushing can be disabled on the authority server, so no one person can rewrite history (aside from the people who have direct file system access to the authority server). Or, think github - people fork a repo, then submit a pull request. Tons of people can commit to a repo, but most commits flow through a trusted few. how granular and how far back can i get this with GIT? If you are asking history, the git history goes back to the very first commit. It is also easy to list the entire history of just one file, and more. how solid is the nonrepudiation factor with GIT? As with a couple answers previous, it all depends on how git is deployed in the organization. The answer will vary from none to rather good, depending on the deployment. for commits - can i see who else might be looking at code? for security If you've granted access to someone to be able to pull from your repository, then no, you can't see who is looking at what. Anyone with pull access will have access to the entire repo. Want finer grained control here without resorting to multiple repositories? Then git is not the right vcs. This is where something like Perforce will win. can i protect others from getting the code? In what way? People who already have some access to the repo? See the above answer. Or Joe Q Public? That is trivial. -- Basically, the big area where something like Perforce (or even SVN I believe) will win is when you need fine grained control over security. E.g. User A only has access to this subfolder, User B only has access to this other subfolder, etc.

kderbe 13y ago

I have no experience with perforce so I cannot directly compare it to git. Some of the things you ask for can be done with git. As eru mentioned, you can sign a commit (and therefore all history leading to that commit), which will prevent anyone else from modifying its history undetected. With abundant signing and tagging, you could probably create a thorough audit trail. Git by itself does not have granular access control, and relies on filesystem permissions for security. The most common tool I know of to finely control write access to git (other than GitHub) is gitolite[0]. But even gitolite only provides read access control at the repository level. [0] What is gitolite? http://gitolite.com/gitolite/index.html#what http://gitolite.com/gitolite/index.html#what