Re: [gitorious] Proper protocol

2011-06-26 Thread martin
On Fri, 2011-06-24 at 22:05 +0200, Christian Johansen wrote:
 For my own servers I would turn off the HTTP protocol for
 push/pull
 anyway...
 
 Why? 

Explanation is below here: 
  
 I like to have http only for the Gitorious web interface. I
 can open
 only SSH and HTTP ports in the router and require login to the
 web
 interface. I use this setup to for my private data.
 
 You can protect HTTP push the same way. The way it's currently
 implemented (thanks to JGit's fantastic API), you can basically
 provide a separate security handler for HTTP(S) push - or even accept
 push through a different host name (which can be protected by a
 firewall and so on).

I want to protect both push and pull... easier to just turn it off...
For data I need to publish I don't use my own servers... 

I strongly believe that most, if not all, software project would benefit
from being published.

But most of the data I have in my private/corp git repositories are not
even software projects. So my use may not be representative for what the
Gitorious project aims for. However I think that lots of private
Gitorious servers contain data that the owners think may be worth
protecting. 

  
 
 Besides... I kind of trust SSH more than anything else in this
 world...
 I will have a hard time deciding to allow any other push
 protocol in my
 own servers...
 
 I'd argue that the HTTPS approach actually has better security. It's
 very restricted, does not require a privileged/dedicated user to log
 in to the server, and is built for this one purpose only. If you have
 specific security concerns, please share.

The https solution is not mature in the same way as the ssh solution.
SSH has protected Unix/Linux boxes for ages.
Software built for one purpose only is not exposed to the same range of
threats and is therefore maturing slower... ssh has been THE target of
hacking attempts since the protocol was first specified back in the
90ies.
I don't understand why you are concerned about the dedicated git user
account... just lock it down properly. You have exactly the same
situation on every ssh server on the planet.

Please keep the SSH and Git protocols at least until it is dropped by
the git project (which hopefully will never happen). 
And I also saw concerns about JGit and writing to the repos. I think all
writing to the repos should be done using code from the git project.

Martin

 
 Christian
 
 
 -- 
 To post to this group, send email to gitorious@googlegroups.com
 To unsubscribe from this group, send email to
 gitorious+unsubscr...@googlegroups.com


-- 
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com


Re: [gitorious] Proper protocol

2011-06-26 Thread jarrod . roberson

On , Marius Mårnes Mathiesen marius.mathie...@gmail.com wrote:
Anyone subscribed to this list will know that installing Gitorious is not  
for the faint of heart. There are a lot of moving parts, a lot of  
dependencies, and getting everything right is difficult. I really want to  
change this.


The question is: once we have an easily installed,  
anonymous/authenticated, pull/push solution for Git traffic: is it time  
to deprecate the other protocol handlers in Gitorious:



- The SSH handler
- The Git handler (git-daemon or git-proxy)




Would anybody miss them?


Yes, lots of people disable the HTTP support completely and only use SSH  
for writes and Git of read only access. This is what we do for our  
installation.
This is very important for work flows where people should be able to check  
out read only copies but not be able to write.


All my Java projects, and there and dozens and dozens of Java repos in my  
Gitorious install, use Maven 3 and its support for the maven-release-plugin  
and scm-plugin which it uses to update Git automatically when preforming  
releases.
the SCM plugin likes to have a developer url and a guest url so it can  
publish documentation with links that people can checkout the code but not  
be able to write to it.


We only give write access to people that are responding to merge requests  
and use the git protocol for adding remotes to private clones to pull from  
the mainline repository.


This separation of concerns is very important to workflows like this.

If you want to enhance the HTTP, then by all means do that, but don't  
remove any functionality that is already there and working great.


PS: As to the difficulty in installing Gitorious. It took me most of a day  
and a half to get it up and running on a CentOS 5.5 server. Most of the  
time was me dealing with all the very specific versions of Ruby stuff that  
wasn't available via any one YUM repository. I do just about every language  
but Ruby and it ecosystem, there were lots of things I just had to guess at  
until I got it right. In particular setting up Passenger details under  
Apache 2.2.x entailed lots and lots of Googling and emails to the group and  
IRC chats, because most of the Passenger documentation refers to config  
files and things with the assumption you know where they actually are.  
Gitorious wasn't stable until I got this nailed down.


There is already what looks like a nice Chef recipe for Ubuntu, we don't do  
Ubuntu because we have standardized on RHEL5/CentOS5 because that is what  
all our clients use, an RPM package and a custom YUM repository for  
RHEL5/CentOS5.x that at least consolidated all the very specific  
Ruby/Rails/Passenger details into a single RPM and have dependencies on all  
the other stuff like Apache, MySQL, etc. would go a long way to a more  
painless adoption.


--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com


[gitorious] Private repositories authorization

2011-06-26 Thread Madhurranjan Mohaan
Hello All,

I have enabled private repositories on my gitorious but after authentication
the users can view all the repositories . I would like the users to view
only those repositories that they are authorized to see/part of .What is the
best way to do this ?

thanks

Madhurranjan

-- 
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com


[gitorious] Re: Private repositories authorization

2011-06-26 Thread Madhurranjan Mohaan
Hello Again,

I went through this conversation -
http://groups.google.com/group/gitorious/browse_thread/thread/2302d21b11220cc0/f7c83844b6557cf8?lnk=gstq=authorization#f7c83844b6557cf8.
This was in 2009 . Want to know if anyone is utilizing this approach ,
if
yes , how has it worked ? Request for inputs.

thanks again.

Madhurranjan

On Sun, Jun 26, 2011 at 11:37 PM, Madhurranjan Mohaan 
madhurranjan.moh...@gmail.com wrote:

 Hello All,

 I have enabled private repositories on my gitorious but after
 authentication the users can view all the repositories . I would like the
 users to view only those repositories that they are authorized to see/part
 of .What is the best way to do this ?

 thanks

 Madhurranjan


-- 
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com


Re: [gitorious] Proper protocol

2011-06-26 Thread Rodrigo Rosenfeld Rosas

Hi Jarrod,

I would be happy to merge any changes to my Gitorious Chef recipe for it 
to work on CentOS/Redhat too. I can download a CentOS image for testing 
it and I can help you with Chef specific bits as long as I understand it.


It just happens that there is a long time since I last used Redhat (last 
version was 9 when Fedora was born and I changed to Suse at that time if 
I remember correctly). I use Debian for several years now and I never 
worked with something like yum in Redhat, Suse, Mandrake, Conectiva or 
Mandriva. The only tool available at that time (that I knew) was rpm 
which is dpkg equivalent.


If you want to help supporting CentOS in the Chef recipe, get in touch 
with me and we can help each other.


Cheers, Rodrigo.

Em 26-06-2011 14:42, jarrod.rober...@gmail.com escreveu:

On , Marius Mårnes Mathiesen marius.mathie...@gmail.com wrote:
 Anyone subscribed to this list will know that installing Gitorious 
is not for the faint of heart. There are a lot of moving parts, a lot 
of dependencies, and getting everything right is difficult. I really 
want to change this.


 The question is: once we have an easily installed, 
anonymous/authenticated, pull/push solution for Git traffic: is it 
time to deprecate the other protocol handlers in Gitorious:


 - The SSH handler
 - The Git handler (git-daemon or git-proxy)


 Would anybody miss them?

Yes, lots of people disable the HTTP support completely and only use 
SSH for writes and Git of read only access. This is what we do for our 
installation.
This is very important for work flows where people should be able to 
check out read only copies but not be able to write.


All my Java projects, and there and dozens and dozens of Java repos in 
my Gitorious install, use Maven 3 and its support for the 
maven-release-plugin and scm-plugin which it uses to update Git 
automatically when preforming releases.
the SCM plugin likes to have a developer url and a guest url so it 
can publish documentation with links that people can checkout the code 
but not be able to write to it.


We only give write access to people that are responding to merge 
requests and use the git protocol for adding remotes to private clones 
to pull from the mainline repository.


This separation of concerns is very important to workflows like this.

If you want to enhance the HTTP, then by all means do that, but don't 
remove any functionality that is already there and working great.


PS: As to the difficulty in installing Gitorious. It took me most of a 
day and a half to get it up and running on a CentOS 5.5 server. Most 
of the time was me dealing with all the very specific versions of Ruby 
stuff that wasn't available via any one YUM repository. I do just 
about every language but Ruby and it ecosystem, there were lots of 
things I just had to guess at until I got it right. In particular 
setting up Passenger details under Apache 2.2.x entailed lots and lots 
of Googling and emails to the group and IRC chats, because most of the 
Passenger documentation refers to config files and things with the 
assumption you know where they actually are. Gitorious wasn't stable 
until I got this nailed down.


There is already what looks like a nice Chef recipe for Ubuntu, we 
don't do Ubuntu because we have standardized on RHEL5/CentOS5 because 
that is what all our clients use, an RPM package and a custom YUM 
repository for RHEL5/CentOS5.x that at least consolidated all the very 
specific Ruby/Rails/Passenger details into a single RPM and have 
dependencies on all the other stuff like Apache, MySQL, etc. would go 
a long way to a more painless adoption. --


--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com


[gitorious] Can anybody suggest Or give me the Procedure of THE LINUX PORTING ON TO HAWKBOARD WITH SOURCE AND TOOLS

2011-06-26 Thread prashant ganappa
hi;

 I am student ; doing my intern project ; So  Can anybody suggest Or
give me the Procedure of  THE LINUX PORTING ON TO HAWKBOARD  WITH
SOURCE AND TOOLS ...


Thanking You  Regards;
Prash

-- 
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com