Does Perforce support "signed revisions" or "signed commits"?

Question

My company is trying to satisfy PA-DSS requirements for our application, one of which is quite ambiguous regarding "secure source control", however our auditor has interpreted it as a need for signed revisions. I see "signed commits" in git and Hg but have discovered nothing on the perforce side.

The auditors example as to what he wanted to see is as follows:

"The payment application vendor maintains source code integrity throughout the development process by using a standard hashing algorithm that is created and validated upon code check-in and verified when source code is checked out for modification. The hashing algorithm used is: • (Example)SHA-256 • (Example)SHA-512 • (Example)MD5"

If you look at http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, in the "Features" table, there is a column for "Signed Revisions" and the perforce section says "Yes"...somebody thought it had support of some kind.

Is this something that could be accomplished using before/after commit triggers? Produce a hash in the before-commit, persist it (somehow) and check it against the one we create in the after-commit? I only learned about perforce triggers 5 minutes ago so I don't even know if they would support the concept (not sure how to persist a value across trigger events, not sure if I have access to file contents on a before-checkout trigger, etc).

Answer 1

Indeed, files which are submitted to Perforce have cryptographic digests which are computed during the submit operation.

These file digests are subsequently checked each time the files are synced to any client workstations, and can also be re-verified directly on the server by using the 'p4 verify' command to determine if the file content has been attacked directly on the server.

You can also observe these digests by running various commands; for example you can run 'p4 fstat -Ol //depot/src/file.c' and look at the 'digest' field.

By the way, what are "PA-DSS requirements"? That's a new acronym to me.

Here's a certain amount of information about the file digests that the Perforce server maintains:

1. http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_verify.html
2. http://kb.perforce.com/AdminTasks/BackupAndRecovery/BadErrorsFromP4Verify
3. http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_fstat.html

If the issue involves maintaining a record of the code review process, to establish that the code changes that were reviewed are the ones that were actually submitted, you might develop a workflow that is based on the Perforce "shelve" command.

The most important aspect of the "shelve" command that helps with these sorts of workflows is actually in the "submit" command: "p4 submit -e " directly submits a shelf on their server, without re-transferring the files from the user's workstation.

Therefore, if your process only allows 'submit -e' for submits to certain protected areas of your repository, and only allows submits of shelves that have been reviewed (these would be things you would enforce with your change-submit trigger), then you have confidence that the code that was reviewed is the code that was submitted.