Re: Git push over git protocol for corporate environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 1 Oct 2009, Eugene Sajine wrote:

> Thanks to everybody for prompt answers!

You are welcome!

> There is one thing I'm still missing though. Do I understand correctly that  
> if a person has an ssh access (account) to the host in internal network,  
> then this won't be enough for him to be able to push to the repo? Should we  
> still go through the hassle of managing the ssh keys for each particular  
> user who is supposed to have push access?

Yes, it is enough to push (and fetch) via SSH protocol.

Nevertheless it is better to use key-based authentication, or to be more
exact passwordless authentication, so that you are asked for ssh key
password (if there is one set for given key) only once when adding it
to ssh agent (c.f. ssh-add, ssh-agent, and keychain).  Otherwise you 
would need to give password over and over (well, I think git uses one
or two connections for fetch / push, so it shouldn't be much of an 
issue).

Also you can have SSH key shared via networked filesystem...


Conversely, on the other hand side many git management tool require to
setup only single SSH account, and distinguish between users based on 
keys they use.

> 
> I believe the answer is yes and that's why I'm leaning towards pulls and  
> pushes over git protocol. There is no solution yet which would be as  
> effective and simple to maintain. Using git protocol will not add security,  
> but it won't be worse than existing CVS or any other centralized version  
> control security model. As soon as security comes into play, then we will  
> need some other solution, but currently i didn't see anything that would be  
> easy to sell to the company.

Git protocol is anonymous and unauthenticated, so you can't (I think)
make any ACL with it.  CVS pserver was not secure, but CVS tunnelled over
SSH, or used over SSH was.


Gitosis, Gitolite, SCuMD, repo are all git management tools.  
GitHub:FI, Gitosis, Girocco (with github), InDefero are all git hosting
tools (with web interface both for repo browsing and for administration).
Gerrit is git based review board.


> Github is cool, but FI is way too expensive and very hard to sell.
> 
> Gitorious is even better!! for corporate use, i think, because of its team  
> oriented approach, but... man... I would kill for java implementation or  
> anything as simple as that!!

Gitorious is roughly GitHub equivalent, as it is also git hosting
software (a web application).

Both SCuMD and (I think) Gerrit are in Java; SCuMD is SSH server and/or
git repository management tool in early stages of development,  Gerrit
is multi-repo management web app and (mainly) review board.

> As i see It is impossible to install in   
> network without internet access, and the amount of dependencies which you  
> have install/pre-install is enormous. I read somewhere ruby on rails is fun  
> to develop with, but is a nightmare to deploy and maintain, and it seems to  
> be true. Come on, guys!! Look at the Hudson CI - one war file containing  
> everything you need, application starts from command line "java -jar  
> hudson.war" and runs on any port you specify. Time to start from download  
> to having first build is less the 10 min!!! If there are gitorious guys -  
> please, think about it and don't forget to share the profit;)!

I don't know what are tricks that Rubyists use to ease deployment, but
take a look at things such as Gems and Capistrano.

> 
> I think Cgit can be something competitive - although i failed to run it  
> yet, having some issues with build...and as all other web based stuff, you  
> should implement something in order to create and set up bare repos on the  
> server automatically (even probably edit the config file via script) to  
> avoid a mess and to avoid one guy spending his time adding and configuring  
> repos... Probably we will and up using gitweb as it at least knows to scan  
> a folder for git repos...although it also gives me troubles installing...  
> both with cgit and gitweb are conducted under cygwin, so probably this is  
> the real problem with them;)

Both cgit (which is written in C) and gitweb (which is single Perl script,
plus CSS and two images) are git web interfaces.  They do not have
features for managing repositories, nor for managing access to git 
repositories.

Girocco, which is git hosting software that http://repo.or.cz uses to
manage git repositories, uses (enhanced) gitweb for web interface.

> 
> I think that this is what is missing right now in order for git to get  
> rocket start and spread inside companies: secure and easy to maintain  
> mainline hosting.

Paraphrasing known quote: Git development community have no plans for
world domination; it would be purely accidental side-effect ;-))

Spread inside companies is not a goal; best possible tool for OSS
development is.

> 
> Probably all my frustration comes from lack of experience - so, while i  
> will continue to work on it, i would really appreciate any advice,  
> especially about experience using git not for open source and not in 3  
> person's team.

You didn't mention trying Gitosis or Gitolite, which are I think most
commonly used tool for managing git repositories (well, Gitosis is 
anyway).  Gitosis is even mentioned in "Pro Git" book (http://progit.org).

See e.g. "Hosting Git repositories, The Easy (and Secure) Way"
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
(from http://git.or.cz/gitwiki/BlogPosts)


[cut rest of reply; please do not toppost, and remove parts of reply
you are not responding to].
-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]