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).
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:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_verify.html
http://kb.perforce.com/AdminTasks/BackupAndRecovery/BadErrorsFromP4Verify
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.
Related
Is there a way to create a review in Swarm to files without changing them?
My Use Case:
I was asked to review an exist module in the project. I want to make an online review using Swarm and add comments.
Update
From Swarm Documentation:
Post-commit model
The post-commit model can be used if your team's development processes preclude the use of shelving. Code must be committed to the Perforce service before code review can begin, which reduces the opportunity to fix problems before, for example, a continuous integration system notices problems. However, code reviews can be started for any existing code regardless of how long it has been committed.
I think that documentation is talking about having the CL committed first and later review it. I'm talking about an exist code that was developed over period of time and with multiple CLs that need a complete review.
The idea is that I want a program that can edit a file yet I, the programmer, cannot edit or forge the file. Encrypting the file is an obvious choice, but even then, I'll still have to keep the encryption key secret from myself somehow.
Obscuring the secret doesn't seem to work, because I could just use the de-obscuring part of the code that I would need for the program.
I'm asking this because I'm trying to make a program that will keep me productive by monitoring my activities, and tell my friends/boss/family just how terrible a procrastinator i am if i don't live up to the goals i set the previous day (in other words: Present me can force future me to not procrastinate)
It seems the content of the program doesn't matter that much but you want to assure that the timestamp and content of the log can't be forged. I suggest writing the log to some external site where you can put data to but not delete from.
Writing false values to the log can only be prevented by having a log which progresses by time. For example, if you hide expenses from your bank account you'll run into problems because future balances will be lower than expected.
For short pieces of information like your account balance, just write it to some public site like Twitter. AFAIK it's not possible to send twitter messages like there were sent some time before.
For more complex data like the progress of a software development project push your changes with a version control system like git to a remote repo where you can't delete or overwrite history.
Update: As you explained in the comments you want to log dinstinct data on your computer that could be forged to anything. IMHO it's virtually impossible for you to write a program on your own which runs on your own computer with root but cannot be controlled. The only kind of software that is somehow similar to your request is DRM software that is calling home to prevent software "piracy". You need a binary program written by somebody else or with the source code deleted. It would need some kind of encrypted and obfuscated network communication which you can't understand.
I think there is not much hope for you using this approach. Better learn to control yourself and not answer random questions by strangers on Stackoverflow, ehem.
I have just installed Mercurial 1.9.3 on my Centos 5.5 x64 server. I'm publishing my repositories using hgweb.wsgi and with mod_wsgi.
This server is only for use by our internal codebase and development team so I've also protected my server using .htaccess and basic HTTP authentication. This is all good and I can clone repositories to local and push changes back to the central repo(s).
There is one thing I'm not understanding correctly which is how to control and manage users.
For example, I have two users in my central repository server .htpassword file: bob and kevin.
On each of bob and kevin's local machines they have their own Mercurial .hgrc files with their username settings configured.
However these .hgrc users appear to have no relation at all to the user's specified in the remote server's .htpassword file.
This means that I can end up with pushes to the central repository coming from "Mickey Mouse" and "Donald Duck" which isn't useful.
How do I enforce end to end mapping of the local .hgrc username to the .htpassword user to maintain, i.e. ensure that the user specified in .hgrc matches the .htpassword user?
This isn't exactly an answer, but it's worth saying: Everyone worries about this at first, but in practice it's just not a problem.
At the time a user is committing with a DVCS, be it Mercurial, git, or other, they're not necessarily connected to any authentication/authorization system you control, so their commits are necessarily committed (locally) with whatever authorship info they want to assert. You can later reject those changesets upon push to a repo/server you control, but that will be a big hassle for you and for them. It's not just a matter of re-intering their name/password they have to alter the history of that changeset and all subsequent changesets to change that authorship information.
The list of completely unsatisfying solutions to this is:
reject pushes where changeset authorship doesn't match authenticated users using a hook (in practice this sucks because developers pull from one another and push one another's changesets all the time)
make developers sign their changesets with the gpg extension or hgsigs (a huge hassle and they'll forget)
keep a pushlog on the server that records the authenticated user that pushed each changeset separate from its authorship (Mozilla does this, and it's less of a hassle that than others but still not likely to ever be consulted).
If you positively can't risk bogus changesets entering a specific repo then use a human filter where people push to shared repo A and only reviewer/buildmanager/you can push from repo A to repo B, where repo B is where official builds come from. Mercurial itself uses this system.
In the end my advice is to not worry about it. Developers worth hiring are proud to put their name on their commits, and if you don't have developers worth hiring you're doomed to failure already.
How do I enforce end to end mapping of the local .hgrc username to the .htpassword user to maintain
No ways to do it. But (instead) ACL extension + ssh (hg-ssh or mercurial-server) gives more predictable results
PS
[ui] username =
usable and have sense only in changeset-comment context just as note, nothing more
Say I've got a \\Repo\... repo. Currently devs generally tend to do all their work directly in there, which normally isn't a problem for small pieces of work. Every so often, this approach fails for various reasons, mainly because they're unable to submit the incomplete change to Live.
So, I was wondering, is there a way to enforce on the server that:
1) no files can be directly checked out from \\Repo\...
2) users then branch to a private area (\\Projects\...)
3) dev, test, submit, dev, test, submit, ...
4) on dev complete, they can re-integrate back into \\Repo\...
I guess the last part is the problem, as files need to be checked out! Has anyone implemented something similar? Any suggestions are much appreciated.
There is no way (that I know of) to enforce this type workflow in P4. You could try to enforce it by setting commit triggers, restricting permissions, or locking files however I believe it would only result in more work (micro-management) and frustrate you and your team.
The best way to establish and enforce any SCM workflow is to set as company/studio policy. Your team should be responsible/able to follow the set procedure and determine (by themselves or through discussion) if an issue is able to be fixed in the main line.
One note about the proposed workflow; creating a new branch for every issue will eventually cause issues and at some point you will need to perform maintenance on the server to conserve disk space and depot browsing speed.
For more information (over) branching on Perforce read this Perforce blog entry from 2009: Perforce Anti-Patterns Part 2: Overuse of branching.
In many studios using Perforce, most developers have their own "working" branch which they continually re-use whenever there are changes that are not safe or able to be performed in the main line.
if i understand your questions properly, you should try with shelving features and working offline features of Perforce. Process is main thing to achieve success in this senario. So you might need to setup a right process to execute this.
For more Info about shelving and working offline with perforce, you can try following links...
http://www.perforce.com/perforce/doc.current/manuals/cmdref/shelve.html
With perforce, a user can get email notifications of changes to a particular file or directory by specifying it in the Reviews field of the user record (more details in the Perforce documentation).
However, I would like to have email notifications sent to a team mailing list, which is of course not a perforce user. One kludgy way of accomplishing this would be to have a team member put the mailing list in for his email address, while another would be to create a user account for the mailing list (would this require another license?). Surely there has to be better way, though.
If you would like to use a user review field, you are entitled to a free "background user" license that might fit your needs (this way, none of your "real" users would need to change their email address):
A "background user" is a Perforce user
account that is used solely for
automated tasks, such as triggers and
daemons. Perforce customers with
current licenses can have an
additional user added to their license
file, free of charge, on request.
Contact Perforce support for more
information.
Or, you could look into doing what you need with some sort of p4 trigger.
The perforce Review daemon is just a python script available here that runs on the server ( or any machine for that matter ) and polls check-ins on a regular interval and then mails users based on what they have set in the review field of their clientspec.
There's no reason why you can't modify it and extend it to do whatever you want including mailing a team mailing list if you want instead.
I've always rolled my own review daemon ( using the vanilla daemon as a starting point )
Old question, new answers (in 2014).
There are now more than one way to do it:
p4review.py - the original (example) script.
p4review2.py - a rewrite of p4review.py with more features and options.
p4notifyd.pl - a Perl version.
Perforce Swarm - a web-based code review system with email notification support built-in.