61–70 of 96 posts
sudo chsh -s /bin/bash git
Isn't that a huge security downgrade from using gitolite? Am I missing something?
[1] https://github.com/gitlabhq/gitlabhq/wiki/From-4.2-to-5.0
I ended up installing gitblit and was amazed by the quick installation and features. Unpack&run! I can recommend gitblit to everyone who needs a quick&easy to install Git web frontend..
But gitlab definitely looks nicer, probably can do even more.. it has pull requests which are (yet) missing in gitblit.
Congratulations, the project looks good. I will keep it in mind. I didn't install sometime ago partially because I was already running a Gitolite instance and wasn't sure it would play nice. Great to see Postgres support, can I ask why MySql is the recommended DB? The install instructions are still quite long but it is really good to see them done properly with a separate non-root user. The suggested Ruby version isn…
About MySql, it is the db that most existing installations use and it is well tested. Also we had problems with deadlocks on Postgres during integration tests on Travis CI. I must admit that I think Postgres has the momentum and look forward to recommending it in the future. Good point about the ruby version, I made a pull request https://github.com/gitlabhq/gitlabhq/pull/3305
So I've been poking around the upgrade instructions for moving to gitlab-shell [1] and I notice you ask the user to do this: sudo chsh -s /bin/bash git I don't see it changing to anything else later in the instructions. Isn't that a huge security downgrade from using gitolite? Am I missing something? [1] https://github.com/gitlabhq/gitlabhq/wiki/From-4.2-to-5.0
However, if the .ssh/authorized_keys file were to be written erroneously, it is possible that this change may increase the likelihood of receiving a shell with the privileges of the git user and thus being able to affect repositories. However, it should not be possible on a system otherwise secured for such a user to obtain access to the rest of they system.
ruby, java, python, php are just too fat.
Earlier quoted context omitted.
We don't have minimum requirements. We run GitLab.com with 3000+ users on a moderate (c1.medium, 1.7 GiB) instance. I think you will do fine with GitLab 5.0 and the 512 Linode. Might have to tune the default parameters a bit to have less processes running.
In order to run GitLab w/o any tweaks you need 1GB Linode. You can start it on 512 but you need to setup unicorn to use only 1 worker and you need at least 200MB of swap
Maybe someone who has the knowledge can write tutorial about configuring GL to run on average VPS?
So I've been poking around the upgrade instructions for moving to gitlab-shell [1] and I notice you ask the user to do this: sudo chsh -s /bin/bash git I don't see it changing to anything else later in the instructions. Isn't that a huge security downgrade from using gitolite? Am I missing something? [1] https://github.com/gitlabhq/gitlabhq/wiki/From-4.2-to-5.0
If GitLab security were to be perfect, then this change would not affect security in any which way. However, if the .ssh/authorized_keys file were to be written erroneously, it is possible that this change may increase the likelihood of receiving a shell with the privileges of the git user and thus being able to affect repositories. However, it should not be possible on a system otherwise secured for such a user to o…
Yes, it does: right now users can use ssh to push and pull repos on my machine using gitolite but they do not have shell access to the computer. "ssh git@gitlab.example.com" just prints a short message and exits. With this change they can all just ssh into the computer and have a bash prompt. Trying to make that secure requires a whole different level of paranoia than just not letting people in in the first place.
It also means that every gitlab user has access to every repo that's hosted and the permissions in the web interface are just for show.
If this is really the case and the attitude of the devs then I don't think I will be updating any time soon...
However, I still feel I must be missing something because the gitlab guys host private repos at gitlab.com and so they must have worked these security things out, right? I can't create an account at gitlab.com and just ssh into their server. At least, I really hope I can't.
Last time i was installing gitlab after having the nightmare to install and maintain a gitorious installation and was really depressed that it felt like the same nightmare. Pages of pages of copy&paste instructions, followed by half a dozen issues that needed post-install fixing... no, never again.. I ended up installing gitblit and was amazed by the quick installation and features. Unpack&run! I can recommend gitbli…
I looked at GitLab, Gitolite + gitweb, and Gitosis. GitLab's installation was the worst of the three. It was horrible, and seemed like it would have been impossible to maintain/upgrade. I really hope that the entire experience has improved.
I ended up using Gitosis, and while I don't quite like the workflow, the installation was pretty easy (there was a bash script to run that installed and configured everything).
I'm going to evaluate the new version of GitLab, but if the installation process isn't better, I'll just stick with Gitosis.
Earlier quoted context omitted.
If GitLab security were to be perfect, then this change would not affect security in any which way. However, if the .ssh/authorized_keys file were to be written erroneously, it is possible that this change may increase the likelihood of receiving a shell with the privileges of the git user and thus being able to affect repositories. However, it should not be possible on a system otherwise secured for such a user to o…
> If GitLab security were to be perfect, then this change would not affect security in any which way. Yes, it does: right now users can use ssh to push and pull repos on my machine using gitolite but they do not have shell access to the computer. "ssh git@gitlab.example.com" just prints a short message and exits. With this change they can all just ssh into the computer and have a bash prompt. Trying to make that secu…
That command doesn't use the shell set in /etc/passwd at all, and you authenticate successfully, so it must give you a shell, right? No.
I really want to give this a go but would like to have it set up to shadow the state of our repos in Github. Anyone have any experience with doing this? Also, when will the docs be updated to reflect the obviation of gitolite?
For a big team you might want something else, but it's possible to configure two repos as one "remote" so that a push goes to both: http://stackoverflow.com/questions/165092/can-i-push-to-more-than-one-repository-in-a-single-command-in-git