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
Related
I'm trying to setup a git server and I want to allow only a specific user to push commits to master branch.
I have tried to use the Linux group permission setting to meet the requirement above but it seems not a correct way.
And I even don't know what are the key words for searching the answer for this.
Any help would be appreciated.
Git does not allow you to have private branches, but you can achieve this functionality by implementing your own server-side pre-receive hook. Github enterprise specific pre-receive hook example is here, as a reference.
However, if you are using Git hosting services (like Github) they might have an option for this. Github, in particular, has an option called branch restrictions, but it requires you to have a paid subscription, unless your project is public.
You have two options:
By far the easiest solution is to use hosting software that already provides this functionality. You might want to look at GitLab, which has free options for both SaaS (hosted at gitlab.com) and self-managed instances (running your own gitlab instance). Or github. Or bitbucket. Or I'm sure there are others I'm not thinking of.
If you really don't want to use any of those, you can implement access control on a simple git server, but it's not so simple. The short (or rather, glib) answer is "hooks" - but a hook is just a script that runs when something happens - like in this case you'd use the prereceive hook, which runs when someone's trying to push and decides whether to accept the push. Now, how does your hook know who is pushing? (The commit metadata does not indicate who's pushing. What you need is authentication around the actual connection, and visibility of the authentication in your script so that the script may implement your authorization rules. That very quickly breaks down into "it depends on your environment".)
Since it's not really possible to exhaustively cover every scenario for doing this manually, hopefully either you'll find a pre-packaged solution you like, or you'll find the above to be enough to get you pointed in the right direction to do it manually.
Can we add multiple git-web URL for a single git server. So that specific people can access their projects with their own URL'S?
When I have tired to search the results for above question, it is there like git daemon is used? If it is so? How it is useful?
It is easier, especially with a Git repository hosting server managed by Gitolite, to:
access the same server
And:
different repositories (one per user)
OR different branches (one per user) within the same repository.
As to that last option, you can read "Gitolite: Personal branches":
"personal" branches are great for environments where developers need to share work but can't directly pull from each other (usually due to either a networking or authentication related reason, both common in corporate setups).
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.
I have trac set up together with subversion. I want to allow some people to be able to add tickets, but I don't want them to access the repository. There will be other users who will be able to access the repo via trac. Currently I am using Apache 2 for authentication.
How secure is trac? How difficult is it for someone with limited access to access the source via trac?
I am not asking on how to disallow access to the source via trac. I know how to do that.
The question again is: How hard is it for someone without access to the source to hack in and get at the source?
If Trac itself has access to your repository, and it gets compromised, the attacker has access to your repository by definition. In order to protect your repository from attackers taking over your Trac installation, you need to block Trac itself from accessing your repository; this will however also prevent it from giving access to the repository to anybody as well.
A compromised system still has all access permissions that it had before it was compromised, and whoever compromised it can make it do whatever they wish with its access permissions.
Funny thing, you actually can't rely on any answer provided here. I would say the correct approach is to conclude Trac is not that secure (just an assumption) and try to mitigate potential risks.
I assume your goal is to make sure "users" and "developers" can collaborate, but users will not be able to access sources under any circumstances (which is very good, by the way).
There are quite a lot of relevant recipes on the net, but I will provide the simplest one:
put your Trac behind Apache (you did that already)
use mod-rewrite to make sure "users" will not get access to [your URL]/browser, ...
configure Trac permissions as well
[paranoid mode], change default URLs in order to eliminate guessing
Basically, the idea is to filter users as early as possible in order not to rely on Trac's internal security.
You can also use OWASP Zed Attack Proxy Project to test Trac yourself:
The Zed Attack Proxy (ZAP) is an easy to use integrated penetration
testing tool for finding vulnerabilities in web applications.
It is designed to be used by people with a wide range of security experience
and as such is ideal for developers and functional testers who are new
to penetration testing. ZAP provides automated scanners as well as a
set of tools that allow you to find security vulnerabilities manually.
You can set permissions for every Trac user. For example, you can have user accounts that can only access the ticket system, but not the source browser, timeline or wiki.
In particular, you want to not grant the following permissions:
BROWSER_VIEW # View directory listings in the repository browser
LOG_VIEW # View revision logs of files and directories in the repository browser
FILE_VIEW # View files in the repository browser
CHANGESET_VIEW #View repository check-ins
I am not sure what you mean by "secure". Trac will enforce the permissions you have set for all its web access. It will not show the source browser pages to someone who does not have the proper permissions. In addition to that, you will have to configure SVN as well to not allow anonymous repository read access (otherwise they could by-pass Trac and access the repository directly).
This is possible.
trac-admin /path/to/project permission remove <user> BROWSER_VIEW
trac-admin /path/to/project permission remove <user> LOG_VIEW
trac-admin /path/to/project permission remove <user> FILE_VIEW
trac-admin /path/to/project permission remove <user> CHANGE_VIEW
This will remove all repository related permissions. We use trac, works well, haven't had any security problems as of yet.
Your question is hard to answer by nature. If you want to know about known security holes, you should check their own, or your distribution's, bug tracker. Debian doesn't report any security related bugs in trac, for example. So to the best of my knowledge, it is impossible to crack trac itself and gain ungranted access.
Of course, that doesn't mean there are no security holes. It only means they haven't been found by good guys (who would have reported them). But it's the best you can get when it comes to security, short of doing (or hiring people to do) a full source audit.
A friend of mine and I are developing a web server for system administration in perl, similar to webmin. We have a setup a linux box with the current version of the server working, along with other open source web products like webmail, calendar, inventory management system and more.
Currently, the code is not under revision control and we're just doing periodic snapshots.
We would like to put the code under revision control.
My question is what will be a good way to set this up and software solution to use:
One solution i can think of is to set up the root of the project which is currently on the linux box to be the root of the repository a well. And we will check out the code on our personal machines, work on it, commit and test the result.
Any other ideas, approaches?
Thanks a lot,
Spasski
Version Control with Subversion covers many fundamental version control concepts in addition to being the authority on Subversion itself. If you read the first chapter, you might get a good idea on how to set things up.
In your case, it sounds like you're making the actual development on the live system. This doesn't really matter as far as a version control system is concerned. In your case, you can still use Subversion for:
Committing as a means of backing up your code and updating your repository with working changes. Make a habit of committing after testing, so there are as few broken commits as possible.
Tagging as a means of keeping track of what you do. When you've added a feature, make a tag. This way you can easily revert to "before we implemented X" if necessary.
Branching to developt larger chunks of changes. If a feature takes several days to develop, you might want to commit during development, but not to the trunk, since you are then committing something that is only half finished. In this case, you should commit to a branch.
Where you create a repository doesn't really matter, but you should only place working copies where they are actually usable. In your case, it sounds like the live server is the only such place.
For a more light-weight solution, with less overhead, where any folder anywhere can be a repository, you might want to use Bazaar instead. Bazaar is a more flexible version control system than Subversion, and might suit your needs better. With Bazaar, you could make a repository of your live system instead of setting up a repository somewhere else, but still follow the 3 guidelines above.
How many webapp instances can you run?
You shouldn't commit untested code, or make commits from a machine that can't run your code. Though you can push to backup clones if you like.