Re: [gitorious] Can anybody suggest Or give me the Procedure of THE LINUX PORTING ON TO HAWKBOARD WITH SOURCE AND TOOLS
Wrong group. This group is about gitorious, a git hosting web application. You probably wanted to contact a project that is hosted on www.gitorious.org but ended up on the wrong list (not sure what the right one would be - I don't understand the question). Regards, Ben On Sun, Jun 26, 2011 at 4:16 PM, prashant ganappa prashantgana...@gmail.com wrote: 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 -- 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 Sun, Jun 26, 2011 at 10:16 AM, martin mar...@siamect.com wrote: The https solution is not mature in the same way as the ssh solution. SSH has protected Unix/Linux boxes for ages. One might argue that SSH has exposed Unix/Linux boxes to attacks, not protected them, for ages; just have a quick look at the security logs on your server, and you'll discover that SSH is the preferred choice of anyone targeting your server. SSH's will by default offer a connecting user a shell, the gitorious script bypasses this by restricting which actions a user can do on the server. 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. As I mentioned above, I suspect most users running their own Gitorious servers have sshd running as the root user, since otherwise they'd need a separate IP address/port in order to do maintenance on their servers. I don't think it's reasonable to assume people looking for a way to collaborate on code have experience in locking down a SSH daemon on their server. 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. I really don't get this. JGit had a bug, and that bug was resolved. JGit is used in Eclipse by thousands of developers, and they trust it to do its job. JGit is also used in Gerrit, which means the Android repositories would be at stake if JGit didn't work. I don't think they'd use that if there was a real risk in doing so. Furthermore, have you looked at the vulnerabilities in Git over the last few years? You'll find plenty of buffer overflow vulnerabilities, command injection tricks etc. that don't exist in JGit. Would you be as skeptical to for instance the libgit2 project ( http://libgit2.github.com/)? Cheers, - Marius -- 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] Migration from restful_authentication to Devise status update
Fix Gemfile.lock Duplicated (redundant) oauth dependency in Gemfile Removes unused partial view Use 2 spaces instead of tabs in sessions/new.html.erb Remove vendored state-machine plugin as it was already included in Gemfile refactoring: replace vendored hodel_3000_compliant_logger with its gem make reserved? implementation clearer and faster in some cases Fix typo Only caches url reservations after Rails initialization completes You don't need to cherry-pick if you agree with all of them. Just merge with Only caches... for instance... I've just rebased to master. Right. Reviewed, tested and pushed to master! Christian -- 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 Sun, Jun 26, 2011 at 7:42 PM, jarrod.rober...@gmail.com wrote: 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. I'd argue that requiring different URLs for reading and writing is more cumbersome than using the same one and then using authentication/authorization to handle requests to write to the repository. 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. It would be wonderful if someone would step up and take responsibility for .rpm/.deb packages of Gitorious, nothing would be better. Last time I checked there weren't packages for some of the dependencies (activemq, sphinx), they'd need to be maintained as well. As for Passenger, it seems Fedora/RedHat won't include that for some time: https://bugzilla.redhat.com/show_bug.cgi?id=470696 Cheers, - Marius -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
[gitorious] Error: ActionController::InvalidAuthenticityToken
Hi, I am trying to install Gitorious in my local computer. I followed some instructions of the web (http://cjohansen.no/en/ruby/ setting_up_gitorious_on_your_own_server) and I managed to make it run, however when I try to login with the admin email I get: ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): vendor/rails/actionpack/lib/action_controller/ request_forgery_protection.rb:79:in `verify_authenticity_token' vendor/rails/activesupport/lib/active_support/callbacks.rb:178:in `evaluate_method' vendor/rails/activesupport/lib/active_support/callbacks.rb:166:in `call' vendor/rails/actionpack/lib/action_controller/filters.rb:225:in `call' vendor/rails/actionpack/lib/action_controller/filters.rb:629:in `run_before_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:615:in `call_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:610:in `perform_action_with_filters' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `block in perform_action_with_benchmark' vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb: 17:in `block in ms' /usr/lib/ruby/1.9.1/benchmark.rb:309:in `realtime' vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb: 17:in `ms' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_with_benchmark' vendor/rails/actionpack/lib/action_controller/rescue.rb:160:in `perform_action_with_rescue' vendor/rails/actionpack/lib/action_controller/flash.rb:146:in `perform_action_with_flash' vendor/rails/actionpack/lib/action_controller/base.rb:532:in `process' vendor/rails/actionpack/lib/action_controller/filters.rb:606:in `process_with_filters' vendor/rails/actionpack/lib/action_controller/base.rb:391:in `process' vendor/rails/actionpack/lib/action_controller/base.rb:386:in `call' vendor/rails/actionpack/lib/action_controller/routing/route_set.rb: 437:in `call' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:87:in `dispatch' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:121:in `_call' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:130:in `block in build_middleware_stack' vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `block in call' vendor/rails/activerecord/lib/active_record/connection_adapters/ abstract/query_cache.rb:34:in `cache' vendor/rails/activerecord/lib/active_record/query_cache.rb:9:in `cache' vendor/rails/activerecord/lib/active_record/query_cache.rb:28:in `call' vendor/rails/activerecord/lib/active_record/connection_adapters/ abstract/connection_pool.rb:361:in `call' vendor/rails/actionpack/lib/action_controller/string_coercion.rb: 25:in `call' rack (1.0.1) lib/rack/head.rb:9:in `call' rack (1.0.1) lib/rack/methodoverride.rb:24:in `call' vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in `call' vendor/rails/railties/lib/rails/rack/metal.rb:47:in `call' vendor/rails/actionpack/lib/action_controller/session/ cookie_store.rb:93:in `call' vendor/rails/activesupport/lib/active_support/cache/strategy/ local_cache.rb:24:in `call' vendor/rails/actionpack/lib/action_controller/failsafe.rb:26:in `call' rack (1.0.1) lib/rack/lock.rb:11:in `block in call' internal:prelude:8:in `synchronize' rack (1.0.1) lib/rack/lock.rb:11:in `call' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in `call' vendor/rails/railties/lib/rails/rack/static.rb:31:in `call' rack (1.0.1) lib/rack/urlmap.rb:46:in `block in call' rack (1.0.1) lib/rack/urlmap.rb:40:in `each' rack (1.0.1) lib/rack/urlmap.rb:40:in `call' vendor/rails/railties/lib/rails/rack/log_tailer.rb:17:in `call' rack (1.0.1) lib/rack/content_length.rb:13:in `call' rack (1.0.1) lib/rack/handler/webrick.rb:50:in `service' /usr/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /usr/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /usr/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' Maybe is because I failed to run one step in the configuration: ruby script/console production Because I get this error: /usr/lib/ruby/gems/1.9.1/gems/bundler-1.0.15/lib/bundler/ rubygems_integration.rb:194:in `block in stub_source_index170': undefined method `skip_during' for Bundler::RubygemsIntegration::Deprecate:Class (NoMethodError) I have ruby 1.9.1p431 (2011-02-18 revision 30908) with gem 1.8.5 The list of gems are: actionmailer (2.3.5) actionpack (2.3.5) activerecord (2.3.8, 2.3.5) activeresource (2.3.5) activesupport (2.3.8, 2.3.5) acts-as-taggable- on (2.0.6) builder (3.0.0) bundler (1.0.15) chronic (0.3.0) daemon_controller (0.2.6) daemons (1.1.0) diff-lcs (1.1.2) echoe (4.3.1) eventmachine (0.12.10) exception_notification (1.0.20090728) factory_girl (1.3.3) fastthread (1.0.7) gemcutter (0.6.1) geoip (0.8.9) hoe (2.8.0) json_pure (1.5.0) mime-types (1.16)
Re: [gitorious] Proper protocol
On Mon, 2011-06-27 at 10:17 +0200, Marius Mårnes Mathiesen wrote: On Sun, Jun 26, 2011 at 10:16 AM, martin mar...@siamect.com wrote: The https solution is not mature in the same way as the ssh solution. SSH has protected Unix/Linux boxes for ages. One might argue that SSH has exposed Unix/Linux boxes to attacks, not protected them, for ages; just have a quick look at the security logs on your server, and you'll discover that SSH is the preferred choice of anyone targeting your server. SSH's will by default offer a connecting user a shell, the gitorious script bypasses this by restricting which actions a user can do on the server. I have in average about 200 logged intrusion attempts on the ssh port per day. I don't allow password authentication... I don't believe that being the primary target for such attempts make ssh any weaker... 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. As I mentioned above, I suspect most users running their own Gitorious servers have sshd running as the root user, since otherwise they'd need a separate IP address/port in order to do maintenance on their servers. I don't think it's reasonable to assume people looking for a way to collaborate on code have experience in locking down a SSH daemon on their server. If people are knowledgeable enough to follow the instructions to install Gitorious, then they should have no problem following a lock-down instruction for ssh! 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. I really don't get this. JGit had a bug, and that bug was resolved. JGit is used in Eclipse by thousands of developers, and they trust it to do its job. JGit is also used in Gerrit, which means the Android repositories would be at stake if JGit didn't work. I don't think they'd use that if there was a real risk in doing so. Furthermore, have you looked at the vulnerabilities in Git over the last few years? You'll find plenty of buffer overflow vulnerabilities, command injection tricks etc. that don't exist in JGit. I don't by default trust people, software nor politicians. I trust what has been proven to work for others and yes I follow the Git developers discussions. I do see a very serious attitude towards problems, especially if it is about security or keeping the data intact. I have used Eclipse for a while and I'm not impressed. I also read how their project management is trying to use hooks to verify that the committers is on the list of trusted people. This shows clearly that they have yet to understand the concept of distributed work flow. So Eclipse using JGit does not making JGit anymore trustworthy, quite the opposite. Anroid... well Google just skipped the plans for supporting Git (for now) and went for Mercurial instead... Not that I care but the comparisons they published speaks... Don't take me wrong, I like Hg too but if I have to choose... it's Git. So really there are others I trust more. The Gitorious team including you for example. Even if you right now are exercising the thought of skipping ssh, there is absolutely no doubt in my mind that you will come to the conclusion that keeping ssh/git is necessary. You don't know if JGit have buffer overflow vulnerabilities or command injection tricks and whatever things are referred to as etc... no one does... the information is simply not there. Would you be as skeptical to for instance the libgit2 project (http://libgit2.github.com/)? Yes, but I'm skeptical to all projects. Over time, some gain my trust and respect. Libgit2 has an odd extension to GPLv2 that should be read carefully... I strongly believe that the best programmers are searching to contribute directly to the git project as long as the git project is aiming in the right direction. There may be strong programmers in libgit2 as well as JGit and there may be competent management too. I don't know. Time has to show... As far as I'm concerned, right now, I push via ssh, pull via git and I think we all should.go ahead with the https push but let the users decide if they trust it. Let the users enable it per project or per repo. Maybe in a few years, I will use it... Martin Cheers, - Marius -- 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
Hi there On Mon, Jun 27, 2011 at 11:17 AM, Marius Mårnes Mathiesen marius.mathie...@gmail.com wrote: On Sun, Jun 26, 2011 at 10:16 AM, martin mar...@siamect.com wrote: 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. As I mentioned above, I suspect most users running their own Gitorious servers have sshd running as the root user, since otherwise they'd need a separate IP address/port in order to do maintenance on their servers. I don't think it's reasonable to assume people looking for a way to collaborate on code have experience in locking down a SSH daemon on their server. Since this came up several times now: Can you explain that part? I wonder if you'd consider my environment at risk. Looking at man sshd_config I think I'm fine: UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is “yes”. But maybe I'm not understanding the concern. So I am running ssh as root (like most users, as you said), but it seems to be the default to enable privilege separation, which kind of ends up doing what you do manually: It runs the network facing service unprivileged. Regards, Ben -- 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
Em 27-06-2011 05:30, Marius Mårnes Mathiesen escreveu: On Sun, Jun 26, 2011 at 7:42 PM, jarrod.rober...@gmail.com mailto:jarrod.rober...@gmail.com wrote: 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. I'd argue that requiring different URLs for reading and writing is more cumbersome than using the same one and then using authentication/authorization to handle requests to write to the repository. 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. It would be wonderful if someone would step up and take responsibility for .rpm/.deb packages of Gitorious, nothing would be better. Last time I checked there weren't packages for some of the dependencies (activemq, sphinx), they'd need to be maintained as well. As for Passenger, it seems Fedora/RedHat won't include that for some time: https://bugzilla.redhat.com/show_bug.cgi?id=470696 Hi Marius, although there is no ActiveMQ package for Debian, there is the stompserver package that could be used instead. Sphinx exists like sphinxsearch package in Debian (I believe in Ubuntu too). There is also 'libapache2-mod-passenger'. Not that it would be simple to write such gitorious.deb package, but I don't think the main reasons are the lack of packages, in Debian at least... :) -- 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] Error: ActionController::InvalidAuthenticityToken
Em 27-06-2011 06:52, Carlos Quiros escreveu: Hi, I am trying to install Gitorious in my local computer. I followed some instructions of the web (http://cjohansen.no/en/ruby/ setting_up_gitorious_on_your_own_server) and I managed to make it run, however when I try to login with the admin email I get: ... Hi Carlos, First, I wouldn't use Ruby 1.9 with Gitorious... Then, how are you accessing your gitorious web application? Are you using the FQDN as set in gitorious.yml? -- 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 On Mon, Jun 27, 2011 at 4:18 PM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: Em 27-06-2011 08:33, Benjamin Podszun escreveu: Hi there On Mon, Jun 27, 2011 at 11:17 AM, Marius Mårnes Mathiesen marius.mathie...@gmail.com wrote: On Sun, Jun 26, 2011 at 10:16 AM, martinmar...@siamect.com wrote: 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. As I mentioned above, I suspect most users running their own Gitorious servers have sshd running as the root user, since otherwise they'd need a separate IP address/port in order to do maintenance on their servers. I don't think it's reasonable to assume people looking for a way to collaborate on code have experience in locking down a SSH daemon on their server. Since this came up several times now: Can you explain that part? I wonder if you'd consider my environment at risk... What Marius is trying to say is that *if you're exposing your Gitorious installation to the web* you *must* make sure you protect it adequately. If you need to expose Gitorious, than it makes sense to disable SSH and go with HTTPS if you don't want to expose SSH to the Internet. Otherwise, you should probably disable password authentication for all users. It would also be a great idea to disallow SSH login with the root account and create another one for logging in instead. Not that SSH is unreliable, but these are best practices if your security concerns are high. Could be. I'm not sure. We're probably all non-native english speakers. I read 'have sshd running as the root user' as 'running the process sshd with effective uid 0', which is the default, with some twists (see the privilege separation thing). I don't know any problems with this and would love to hear any issues that gitorious.org had with this in the past. Maybe I adapt my own setup afterwards. If it the point was purely about securing the box/service itself, disallowing root logins etc, as you understood it, then my point is moot and everything's good/I agree totally. Regards, Ben -- 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
Em 27-06-2011 10:25, Benjamin Podszun escreveu: Hi On Mon, Jun 27, 2011 at 4:18 PM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: Em 27-06-2011 08:33, Benjamin Podszun escreveu: Hi there On Mon, Jun 27, 2011 at 11:17 AM, Marius Mårnes Mathiesen marius.mathie...@gmail.comwrote: On Sun, Jun 26, 2011 at 10:16 AM, martinmar...@siamect.comwrote: 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. As I mentioned above, I suspect most users running their own Gitorious servers have sshd running as the root user, since otherwise they'd need a separate IP address/port in order to do maintenance on their servers. I don't think it's reasonable to assume people looking for a way to collaborate on code have experience in locking down a SSH daemon on their server. Since this came up several times now: Can you explain that part? I wonder if you'd consider my environment at risk... What Marius is trying to say is that *if you're exposing your Gitorious installation to the web* you *must* make sure you protect it adequately. If you need to expose Gitorious, than it makes sense to disable SSH and go with HTTPS if you don't want to expose SSH to the Internet. Otherwise, you should probably disable password authentication for all users. It would also be a great idea to disallow SSH login with the root account and create another one for logging in instead. Not that SSH is unreliable, but these are best practices if your security concerns are high. Could be. I'm not sure. We're probably all non-native english speakers. I read 'have sshd running as the root user' as 'running the process sshd with effective uid 0', which is the default, with some twists (see the privilege separation thing). I don't know any problems with this and would love to hear any issues that gitorious.org had with this in the past. Maybe I adapt my own setup afterwards. If it the point was purely about securing the box/service itself, disallowing root logins etc, as you understood it, then my point is moot and everything's good/I agree totally. I think it is not currently possible to listen on port 22 with effective uid other than 0 in Unix-like systems, but I may be wrong since I'm not really a security specialist. If we set it up to run in another port, than instead of 'git@some.server/some/repo' we would have 'git@some.server:/some/repo'. Maybe someone here with better knowledge on security could state otherwise how to listen on port 22 without running the service with an unprivileged account. -- 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
Em 27-06-2011 10:41, Rodrigo Rosenfeld Rosas escreveu: Em 27-06-2011 10:25, Benjamin Podszun escreveu: Hi On Mon, Jun 27, 2011 at 4:18 PM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: Em 27-06-2011 08:33, Benjamin Podszun escreveu: Hi there On Mon, Jun 27, 2011 at 11:17 AM, Marius Mårnes Mathiesen marius.mathie...@gmail.comwrote: On Sun, Jun 26, 2011 at 10:16 AM, martinmar...@siamect.com wrote: 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. As I mentioned above, I suspect most users running their own Gitorious servers have sshd running as the root user, since otherwise they'd need a separate IP address/port in order to do maintenance on their servers. I don't think it's reasonable to assume people looking for a way to collaborate on code have experience in locking down a SSH daemon on their server. Since this came up several times now: Can you explain that part? I wonder if you'd consider my environment at risk... What Marius is trying to say is that *if you're exposing your Gitorious installation to the web* you *must* make sure you protect it adequately. If you need to expose Gitorious, than it makes sense to disable SSH and go with HTTPS if you don't want to expose SSH to the Internet. Otherwise, you should probably disable password authentication for all users. It would also be a great idea to disallow SSH login with the root account and create another one for logging in instead. Not that SSH is unreliable, but these are best practices if your security concerns are high. Could be. I'm not sure. We're probably all non-native english speakers. I read 'have sshd running as the root user' as 'running the process sshd with effective uid 0', which is the default, with some twists (see the privilege separation thing). I don't know any problems with this and would love to hear any issues that gitorious.org had with this in the past. Maybe I adapt my own setup afterwards. If it the point was purely about securing the box/service itself, disallowing root logins etc, as you understood it, then my point is moot and everything's good/I agree totally. I think it is not currently possible to listen on port 22 with effective uid other than 0 in Unix-like systems, but I may be wrong since I'm not really a security specialist. If we set it up to run in another port, than instead of 'git@some.server/some/repo' we would have 'git@some.server:/some/repo'. Maybe someone here with better knowledge on security could state otherwise how to listen on port 22 without running the service with an unprivileged account. Actually, I hack I usually do when hosting some web application on Tomcat is usually to run it as the tomcat user on port 8080 and add an IPTables rule for directing port 80 to 8080... This could be set up for sshd in a Gitorious server. -- 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
Em 27-06-2011 10:47, Rodrigo Rosenfeld Rosas escreveu: ... I think it is not currently possible to listen on port 22 with effective uid other than 0 in Unix-like systems, but I may be wrong since I'm not really a security specialist. If we set it up to run in another port, than instead of 'git@some.server/some/repo' we would have 'git@some.server:/some/repo'. Maybe someone here with better knowledge on security could state otherwise how to listen on port 22 without running the service with an unprivileged account. Actually, I hack I usually do when hosting some web application on Tomcat is usually to run it as the tomcat user on port 8080 and add an IPTables rule for directing port 80 to 8080... This could be set up for sshd in a Gitorious server. According to this article, it is possible to allow an unprivileged user to bind to privileged ports by using authbind: http://www.debian-administration.org/articles/386 -- 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] Migration from restful_authentication to Devise status update
Great news! I'll try to get devise_ldap_authenticatable ( https://github.com/cschiewek/devise_ldap_authenticatable) to work with gitorious, and learn some ruby on the process. On Mon, Jun 27, 2011 at 5:20 AM, Christian Johansen christ...@cjohansen.nowrote: Fix Gemfile.lock Duplicated (redundant) oauth dependency in Gemfile Removes unused partial view Use 2 spaces instead of tabs in sessions/new.html.erb Remove vendored state-machine plugin as it was already included in Gemfile refactoring: replace vendored hodel_3000_compliant_logger with its gem make reserved? implementation clearer and faster in some cases Fix typo Only caches url reservations after Rails initialization completes You don't need to cherry-pick if you agree with all of them. Just merge with Only caches... for instance... I've just rebased to master. Right. Reviewed, tested and pushed to master! 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] Migration from restful_authentication to Devise status update
Em 27-06-2011 18:14, Pedro Kiefer escreveu: Great news! I'll try to get devise_ldap_authenticatable (https://github.com/cschiewek/devise_ldap_authenticatable) to work with gitorious, and learn some ruby on the process. Don't be too excited Pedro :) Devise was not integrated yet, although it is almost finished lacking a single integration test. The merged commits are not related to Devise, sorry... Anyway, this is just one step in our migration path to Rails 3. After we migrate to Rails 3, we'll be able to upgrade Devise to latest version and use OmniAuth, which will allow integration with LDAP as well as many other authentication providers. But this can take a while... Cheers, Rodrigo. On Mon, Jun 27, 2011 at 5:20 AM, Christian Johansen christ...@cjohansen.no mailto:christ...@cjohansen.no wrote: Fix Gemfile.lock Duplicated (redundant) oauth dependency in Gemfile Removes unused partial view Use 2 spaces instead of tabs in sessions/new.html.erb Remove vendored state-machine plugin as it was already included in Gemfile refactoring: replace vendored hodel_3000_compliant_logger with its gem make reserved? implementation clearer and faster in some cases Fix typo Only caches url reservations after Rails initialization completes You don't need to cherry-pick if you agree with all of them. Just merge with Only caches... for instance... I've just rebased to master. Right. Reviewed, tested and pushed to master! Christian -- 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] Error: ActionController::InvalidAuthenticityToken
From my experience installing gitorious this might be a problem generating secret key to use in gitorious.yml Are you sure you stripped it of all carriage returns? It must be a single line. If you are not sure - try just copying a single line from the output of the security key generator and using it. On Mon, Jun 27, 2011 at 1:52 PM, Carlos Quiros qlands.softw...@gmail.comwrote: Hi, I am trying to install Gitorious in my local computer. I followed some instructions of the web (http://cjohansen.no/en/ruby/ setting_up_gitorious_on_your_own_server) and I managed to make it run, however when I try to login with the admin email I get: ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): vendor/rails/actionpack/lib/action_controller/ request_forgery_protection.rb:79:in `verify_authenticity_token' vendor/rails/activesupport/lib/active_support/callbacks.rb:178:in `evaluate_method' vendor/rails/activesupport/lib/active_support/callbacks.rb:166:in `call' vendor/rails/actionpack/lib/action_controller/filters.rb:225:in `call' vendor/rails/actionpack/lib/action_controller/filters.rb:629:in `run_before_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:615:in `call_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:610:in `perform_action_with_filters' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `block in perform_action_with_benchmark' vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb: 17:in `block in ms' /usr/lib/ruby/1.9.1/benchmark.rb:309:in `realtime' vendor/rails/activesupport/lib/active_support/core_ext/benchmark.rb: 17:in `ms' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_with_benchmark' vendor/rails/actionpack/lib/action_controller/rescue.rb:160:in `perform_action_with_rescue' vendor/rails/actionpack/lib/action_controller/flash.rb:146:in `perform_action_with_flash' vendor/rails/actionpack/lib/action_controller/base.rb:532:in `process' vendor/rails/actionpack/lib/action_controller/filters.rb:606:in `process_with_filters' vendor/rails/actionpack/lib/action_controller/base.rb:391:in `process' vendor/rails/actionpack/lib/action_controller/base.rb:386:in `call' vendor/rails/actionpack/lib/action_controller/routing/route_set.rb: 437:in `call' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:87:in `dispatch' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:121:in `_call' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:130:in `block in build_middleware_stack' vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `call' vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in `block in call' vendor/rails/activerecord/lib/active_record/connection_adapters/ abstract/query_cache.rb:34:in `cache' vendor/rails/activerecord/lib/active_record/query_cache.rb:9:in `cache' vendor/rails/activerecord/lib/active_record/query_cache.rb:28:in `call' vendor/rails/activerecord/lib/active_record/connection_adapters/ abstract/connection_pool.rb:361:in `call' vendor/rails/actionpack/lib/action_controller/string_coercion.rb: 25:in `call' rack (1.0.1) lib/rack/head.rb:9:in `call' rack (1.0.1) lib/rack/methodoverride.rb:24:in `call' vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in `call' vendor/rails/railties/lib/rails/rack/metal.rb:47:in `call' vendor/rails/actionpack/lib/action_controller/session/ cookie_store.rb:93:in `call' vendor/rails/activesupport/lib/active_support/cache/strategy/ local_cache.rb:24:in `call' vendor/rails/actionpack/lib/action_controller/failsafe.rb:26:in `call' rack (1.0.1) lib/rack/lock.rb:11:in `block in call' internal:prelude:8:in `synchronize' rack (1.0.1) lib/rack/lock.rb:11:in `call' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in `call' vendor/rails/railties/lib/rails/rack/static.rb:31:in `call' rack (1.0.1) lib/rack/urlmap.rb:46:in `block in call' rack (1.0.1) lib/rack/urlmap.rb:40:in `each' rack (1.0.1) lib/rack/urlmap.rb:40:in `call' vendor/rails/railties/lib/rails/rack/log_tailer.rb:17:in `call' rack (1.0.1) lib/rack/content_length.rb:13:in `call' rack (1.0.1) lib/rack/handler/webrick.rb:50:in `service' /usr/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /usr/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /usr/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' Maybe is because I failed to run one step in the configuration: ruby script/console production Because I get this error: /usr/lib/ruby/gems/1.9.1/gems/bundler-1.0.15/lib/bundler/ rubygems_integration.rb:194:in `block in stub_source_index170': undefined method `skip_during' for Bundler::RubygemsIntegration::Deprecate:Class (NoMethodError) I have ruby 1.9.1p431 (2011-02-18 revision 30908) with gem 1.8.5 The list of gems are: actionmailer
