Re: [gitorious] Proper protocol
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
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
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
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
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
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