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 obtain access to the rest of they system.
> 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 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.
AUTHORIZED_KEYS FILE FORMAT
....
command="command"
Specifies that the command is executed whenever this key is used for
authentication. The command supplied by the user (if any) is
ignored. The command is run on a pty if the client requests a pty;
otherwise it is run without a tty. If an 8-bit clean channel is
required, one must not request a pty or should specify no-pty. A
quote may be included in the command by quoting it with a backslash.
This option might be useful to restrict certain public keys to per‐
form just a specific operation. An example might be a key that per‐
mits remote backups but nothing else. Note that the client may
specify TCP and/or X11 forwarding unless they are explicitly prohib‐
ited. The command originally supplied by the client is available in
the SSH_ORIGINAL_COMMAND environment variable. Note that this
option applies to shell, command or subsystem execution. Also note
that this command may be superseded by either a sshd_config(5)
ForceCommand directive or a command embedded in a certificate.
Got it, so the shell is still /bin/bash but they specify the command in the .ssh/authorize_keys file which means it cannot be overridden by the user. (I was under the mistaken impression that gitolite overrode the shell and not the command)
So your original point was correct: as long as the authorized_keys file is not corrupted, everything is good. Thanks for helping me understand!
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 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.
Installation is actually a problem with Rails, and web app development as a whole.
Think about PHP: Drop files in the web server directory, add a database and user, edit the app configuration file to point to said database and user, and you're done.
Then there's Rails apps. Gitolite is actually fairly typical: Install a ton of packages (including ssh, redis, and postfix daemons which need to be secured), compile your own Ruby (and keep it up to date), install the Bundler gem, configure Gitlab, configure Gitlab shell, configure Unicorn, configure the database, install gems with bundler, bundle exec rake gitlab:setup RAILS_ENV=production (I have no idea what this does), install an init script, update your rc.d, then set up an nginx reverse proxy [1].
If you're used to setting up web apps, this is typical, and very well-described by the provided instructions. If you're used to the PHP experience, or you've only ever installed distro-packaged apps with apt-get or equivalent, this process feels really unreasonably long and painful.
I remember that the Discourse folks said that they were aware that installation was a pain point, and they were working on making it easier.
Lowering the barriers to installation is actually something that web applications written in Ruby/Python/Node.js really need to do in order to begin to compete with PHP solutions among more casual administrators.
A big part of the problem is isolation from the system package manager. I have a Redmine install on the same server as Gitolite, which I manage via apt-get. I'd really like to have a version of the Gitlab instructions that keeps non-system packages (like the self-compiled Ruby) self-contained in /home/git, so they don't break anything else.
The person who has to install some third party web application is mainly concerned with “how easy is this to install”.
Not only have I steered clear of installing things with too many alien prerequisites, I’m often writing in PHP only because deployment is just so much easier.
In another comment i mentioned installing apache, php, mysql and configuring all that as an ancient way that i was able to tolerate years ago, but not nowadays and not for a quick, single-user installation.
Nowadays you can easily have a webapp configure it self. I don't expect more then install/unpack, run, open browser, configure (in the browser), done! And the configure step shouldn't be much more then a) set up admin password and b) point so some database. And if i only want to evaluate or only want a single-user installation i don't want to install MySQL, i am fine with SQLite or HSQL or some other database that comes with the package.
Downloading a .tar.gz, unpacking to /var/www, editing apache config, editing htaccess, editing some config.php, restarting apache, continuing configuration in browser, installing a mailserver to send mails (wtf) is a rather common way i have seen in the PHP world. Gitlab just happened to make it even worse with post-install fixing known bugs/behaviour that should've been working out of the box.
Of course there are good examples and bad examples in each of those, it's surely not tied to the programming language that is used.
I had the same issue a month or so ago. I needed to install a local Git repository and because I'd be working with people who had never used Git before, I wanted to have some kind of GUI for them.
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.
Gitolite- the old git repo for gitlab- is a cherished joy around here; we love it, it's both easy to use & has mad useful features. qa* users can commit to qa* branches? Sure, np.
I have a hard time sympathizing with Gitolite being removed for it's complexity. GitLab switching to their own stuff to make their side of the equation easier, to make their software less complex to write and configure, otoh might be a thing. I'd just need nominated yesterday to start trying to install it alongside Gitolite!
I wonder if they made a crack at being able to read and parse gitolite.conf files and use those configs to power gitlab? That would've been a happier path for me personally for smoothing out gitlab configuration hell, more so than writing a new repo server that we're not likely to qualify & then adopt, not when Gitolite is our living beating heart.
I'm nowhere near a ruby developer, so i don't understand how most of the things works, but had cero trouble installing gitlab. Even when it throws some strange (for me) errors on some gems, it was just a matter of googling to solve the problem.
Some years back i was able to tolerate when a webapp needed serious fiddling in a) apache configs, b) php configs and c) manual mysql database setup.
Nowaday i expect something to run and have as few steps to install as possible. It wasn't even so much the many steps in between but the stuff that just didn't work as given in the installation guide. Turned out that some answers were in the gitlab Troubleshooting Guide. And then some stuff just didn't work, because at that point resque was removed (if i remember correctly, i don't even know what resque is and i don't really care, tbh). Now, after this took me 2 hours to get it running, half a day was spent with a) log in, b) find something not working, c) google, d) log into server and fix, e) repeat.
I'm no ruby guy, too, but i would've thought this goes much smoother nowadays.
I was using Gitlab for 1 or 2 weeks back then, but when the password reset didn't work it really made me think if i want to go through all that again on the next major update. So i turned to gitblit (which i rejected before because it can't do pull requests).
Edit: Don't get me wrong, i liked the Gitlab interface, it's very polished and nice, and what was working was working fine. Still i wouldn't want to maintain it. Maybe it's all better now with 5.0 :)
I'm sorry to hear you had trouble installing GitLab before. Installation should be a lot better now. We replaced resque with sidekick. Also there are pre installed images available from http://bitnami.com/stack/gitlab
Ah, sounds great. I think you should really advertise those packages more! To be honest the 5.0 installation guide still looks terribly long. No way i would go through that again. BUT now there are packages.. hopefully for 5.0 soon.
Sytse Sijbrandij from GitLab.com here. Thank you for submitting this. We hope people like the change. We put a lot of hard working in making GitLab more stable and scaling it. Let us know what you think.
Its common courtesy to give attributions next to contributed changes in the changelog. I gladly sponsored development of one of them (API: improved return codes and docs, https://github.com/gitlabhq/gitlabhq/pull/2835) and a short nod to the involved persons would be nice.
in the Padrino project, we usually attribute by (GH) nickname, because thats what most programmers build their identity around. Also, all involved are mentioned. In that case, it would be:
- API: improved return codes and docs. (Xylakant, justahero)
About mentioning usernames, I figured it might get a bit confusing when we get public projects on GitLab.com, you would have to guess which platform the username belongs to. What do you think?
I'd like to thank the developers for this great project. I finally convinced my team to switch over from SVN to git after I showed them Gitlab. (GitHub was never an option due to corporate data security policies. Even for GitHub private repos.)
I'm running Gitlab 4.1 with more-or-less the default installation instructions and very light usage currently. I'll upgrade to 5.0 in the near future. Here's what I'm seeing:
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1616 gitlab 20 0 1851m 108m 7112 S 0.0 10.9 7:46.35 ruby1.9.1
1405 gitlab 20 0 967m 99m 7044 S 0.0 10.0 0:26.63 ruby1.9.1
1667 gitlab 20 0 970m 98m 2596 S 0.0 9.9 0:01.36 ruby1.9.1
1670 gitlab 20 0 970m 97m 2488 S 0.0 9.9 0:00.77 ruby1.9.1
$ ps aux | grep [g]itlab
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
gitlab 1405 0.0 10.0 990904 101508 ? Sl Mar19 0:26 unicorn_rails master -c /home/gitlab/gitlab/config/unicorn.rb -E production
gitlab 1616 0.1 10.9 1896392 110880 ? Sl Mar19 7:46 sidekiq 2.6.4 gitlab [0 of 25 busy]
gitlab 1667 0.0 9.9 994156 100412 ? Sl Mar19 0:01 unicorn_rails worker[0] -c /home/gitlab/gitlab/config/unicorn.rb -E production
gitlab 1670 0.0 9.9 994204 100284 ? Sl Mar19 0:00 unicorn_rails worker[1] -c /home/gitlab/gitlab/config/unicorn.rb -E production
This doesn't include Redis or database.
It seems like that's far too high. Why do you need 400MB of runtime data (and 5GB of allocation) in order to generate these relatively simple web pages?
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
Is 1GB really requred for personal use? I thought about buying 256/512 VPS exclusively for GitLab, don't you think it will be enough for personal projects?
Maybe someone who has the knowledge can write tutorial about configuring GL to run on average VPS?
The speed at which this project is evolving is quite impressive. I find myself looking forward the the 22nd every month with anticipation for the next release! Thank you Gitlab team.
I set up gitlab for some "skunkworks" projects at my day job, and it's been really great. The Gitolite dep never bothered me (the gitlab install is well documented), but seems like a good thing.
I have been using Gitlab since version 3 and have found it a joy to work with and I too look forward to the 22nd every month. We use it in our internal network along with Jenkins for CI and a custom built deployment application. It all works very well with 15 developers and QA personnel. The new gitlab-shell hasn't made any difference whatsoever over gitolite and the update went as smoothly as possible.
gitlabhq also offer Vagrant/Chef VM recipes to quickly get set up.
I encourage anyone considering a change to their VCS/deployment set up to give it a try!
The move away from Gitolite is great as I know it was the source of many of install and upgrade headaches however the new component they've replaced it with is very very closely coupled to GitLab.
This could have been a great chance to create a lightweight alternative to Gitolite for other projects to use too.
We are open to proposals and pull requests to do this. It is not very productive to abstract things without a few examples of projects it should be generalized for.
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?
I believe the developers chose to develop on GitHub so the project would get more exposure to the open source community. And because Gitlab.com is more oriented to private repository hosting. [1]
You are right, the orientation towards on-premises installations is why we don't have public projects yet. But with GitLab Cloud the requests for public projects became louder.
Public projects and the need to add every single developer to every single project they needed access to (no concept of teams) were the main reasons we moved from Gitlab to Github Enterprise
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't the latest (even on the 1.9.3 branch) although I'm not sure that matters.
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.
Just yesterday our workplace gained an interest in setting up Gitlab- can we still use our existing Gitolite install, or do we now have to migrate to Gitlab-shell?
We've been extremely happy with gitolite, and I do not see us moving off of that software.
Welp, there goes an obvious good thing we had high hopes would help enrich our infrastructure! Monday is going to be a very depressing day in the office for everyone: we're going to have to go to cgit or some such, and there'll probably be screaming and crying and whaling and self flagellation over that one.
Ya'll should provide an easy to use configuration for using gitlab as a RO mirror of any arbitrary git repository.
Hope you have a lot of great new things in the pipe that gitlab-shell is providing. If configuration was the problem, why not try and scrape gitolite's configuration directly and run gitlab from that? There's certainly another acceptable path- the one you took, creating your own repo server- but I have a hard time qualifying this- as this press release does- as a feature: it's a migration, a lateral jump: there's nothing new that happens, nothing better, it's just a different configuration routine to do what Gitlab and Gitosis.
I wont be suckered by such suavity, but there's a lot of people who would be more enticed by "new super configurable way better than gitolite repo server" as a sales pitch that probably were happy enough running Gitlabs at it used to run that don't really see this as a feature, as they were already on top of it. When releasing features, put the featureful ones foremost.
Any news on supporting a single gitlab instance fronting several load-balanced git servers as backend? Or do both git repositories and gitlab still have to live on same machine?
No news on this, the repo's need to be on a single volume (can be NFS drive or AWS EBS drive). I'm curious to know why you want this. We are looking into sharded file servers for GitLab.com Cloud but that seems a bit different from what you are proposing. If you don't feel comfortable commenting please email support@gitlab.com
HURRAH! Gitlab is an excellent product but Gitolite and Resque were making the baby Jesus cry, ran off with your girlfriend and kicked a kid over on his bicycle.
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