I've implemented 2FA for SVN and Mercurial (not yet for git) for Indefero. I highly recommend showing users the key for their storage - I've had to extract the keys from FreeOTP and Google Authenticator a number of times.
How do you leverage 2FA with LDAP/AD accounts? Do you store/check the key in gitlab and then auth the users against LDAP/AD - or store the key in LDAP/AD?
GitLab developer here! Thank you, Sytse, for answering already, I'm happy to go into a little more depth.
> I highly recommend showing users the key for their storage - I've had to extract the keys from FreeOTP and Google Authenticator a number of times.
I'm curious, in what situation would you need to extract the key while you still have access to it in one of your apps? We have recovery codes for the situation where you've lost the key in your app, but that doesn't seem to be what you're describing. If you're moving from one app or phone to another, you can just turn off 2FA on GitLab and then turn it on again—you'll get a new key.
> How do you leverage 2FA with LDAP/AD accounts? Do you store/check the key in gitlab and then auth the users against LDAP/AD - or store the key in LDAP/AD?
The 2FA flow is the same for regular GitLab users and those backed by LDAP. After the initial username/password auth step, they are presented with the 2FA form. In both cases, the key is only in GitLab.
> in what situation would you need to extract the key while you still have access to it in one of your apps?
I use FreeOTP on Android to store and generated OTPs. Many years ago I had an HTC One (old version). I was listening to music one day and it just died - wouldn't turn on. Thankfully I extracted most of my OTP keys and was able to setup FreeOTP from scratch. If I didn't - I would be in a world of hurt for the ~20 services that may or may not provide recovery codes (I know you do - but just keep in mind phone dying or theft).
Like I mentioned in the previous post - to me a recovery key isn't to be used lightly, in my opinion it should only be used for "oh crap I need to login right now and I don't have my phone".
I'm not saying I don't trust you and recovery codes - I already got burned once and I don't want to be in that position again. My solution is to squirrel away the OTP keys. Besides - I can already get it by using a barcode scanner on the QR code you generate so I'm not sure what we are arguing about.
GitLab CEO here, I'm probably out of my depth and misunderstanding but let me try. I'll see if other people on my team can look into the question too.
Instead of extracting keys don't you want to use backup codes (that we provide)?
2FA for LDAP accounts is an additional safety measure that you need to unlock the account. The key is stored in the same place as with non-LDAP account I think.
> Instead of extracting keys don't you want to use backup codes (that we provide)?
Perhaps my opinion is wrong - but if I replace my OTP generating device (such as my phone) I don't want to use recovery codes I just want to restore FreeOTP and be on my way. Recovery codes to me is "oh shit I need to get to my account right now because of some important reason X and I don't have my phone with me". To give you some background of why - I have about 20 OTP keys in FreeOTP right now - being able to have root access and restore FreeOTP from Titanium Backup is very important to me.
This was particularly annoying when a service does not provide recovery codes. Or even worse (Symantec VIP OTP) they generate a random key generated based on the device - so even if you reinstall it you can't get the same key back (according to reviews in the play store - updates have even triggered a regen of keys) - locking people out of their accounts because many services who use Symantec VIP access don't offer recovery codes.
This all goes back to the idea of exporting keys from apps like FreeOTP and Google auth. People have asked numerous times but no one wants to implement it in those applications (there is a 3rd party OTP app that claims to store the keys encrypted in dropbox...but last time I used it the automatic backup stopped working....).
To make a long story short - if you present the QR Code I can get the key by using it a barcode scanner - but just tell me what it is so I can throw it in my password manager in the event I need to get into my account without my phone or have to replace my phone.
We can talk offline if you are interested and I can explain how I do 2FA for SVN and Mercurial.
Thanks for the background. If I understand correctly you want functionality that is not common in other application. We don't want to be on the bleeding edge here, we're no crypto experts and prefer to keep things as simple as possible.
Hi nadams, I just replied to your original post, at the same time you posted this one. If you have any questions that aren't answered in that reply, feel free to ask!
Not really related to topic, but how is GitLab CE & GitLab EE project maintained in term of source code? GitLab EE is fork of GitLab CE such that additional code of GitLab EE is in different directory (so upstream changes will not conflict with GitLab EE)?
Thanks for asking. GitLab CE and EE are different repo's. GitLab EE is a superset of the CE code. We merge CE into EE a couple of times per month. Sometimes changes in CE conflict with EE, the GitLab company team takes care of that. For more information please see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/rele...
I wish more people would be upfront like you are. So often do I see really biased answers/responses on the internet, only to realize the person responding works for the company they're defending.
I love that GitLab has their code publically viewable. It provides another example of a large Rails application which is always useful as a way to "see how other people approach challenges" as well as my favorite "why the heck doesn't this work" problems that surface when implementing CI/RSpec, etc.
I recently switched from Github to Gitlab (although only for private projects). In the past I'd used Bitbucket but I disliked the interface. Gitlab, on the other hand, is much better. I think overall I still prefer Github, but it's nice to have unlimited private repos and Gitlab is approaching being as good. It's a remarkably polished project.
Thanks for your kind words Tim! We are happy to offer everyone unlimited private repos on GitLab.com https://about.gitlab.com/gitlab-com/ What can we improve so you would prefer GitLab over GitHub?
Wait, really? Oh. I host it myself, I figured it'd cost for private repos at GitLab.com. Probably should have checked that :-)
Regarding improvements, I don't really have any specific examples. Just keep at it and I'm sure that, over time, you'll refine it until it's perfect. It's really great as it is.
If someone forks CE and adds features missing in CE but present in EE, will GitLab accuse them of looking at the EE code and violating the license? Will that accusation stick?
Open core is a double edge sword, but we try to enlarge the advantages (resources to do release management, fix bugs, upgrade dependencies, investigate security reports) and minimize the downsides (no artificial limits in CE, no crippleware).
Looking at the EE code is fine but you can't use the code. So merge requests that add EE code into CE will not be accepted.
The point being made above seems to be "Releasing the source for EE poisons dev efforts", because if I fork CE and add code that does something EE adds, GitLab might claim that I "stole" code from EE, or looked at EE and was tainted with knowledge from EE code.
Even if I hadn't copied code from EE, the claim could be made and would be destructive to the ability of community members to fork and improve the open source codebase
I expect that in most cases we'll be able to tell from the code. In cases where we can't tell we assume that people made it themselves. We are releasing the code to make EE easier to work with (having private repos and docker images is hard). We did not want to make it harder to contribute EE features to CE. If people are worried about poisoning please let me know. Merging EE functions into CE has always been at the discretion of the core team, we don't need any excuses.
That is super cool. Thank you for demonstrating that it's possible to be a CEO of a successful, community-friendly proprietary version-control company without turning into Larry McVoy.
> Merging EE functions into CE has always been at the discretion of the core team
If someone independently implements all of the EE functions without looking at or using the EE code, will the core team reject the patch due to the fact that it would give a reason for customers to stop paying for EE? Is there any scenario where the core team would accept such a patch?
We advise people to submit one function at a time, this speeds up the process and makes it easier to incorporate feedback. If there is a high quality merge request for an EE feature we'll probably merge it. We hope that instead of duplicating work that has been done most people will focus their efforts on the 180 features marked accepting merge requests http://feedback.gitlab.com/forums/176466-general/status/7964... By the way, some people in the core team https://about.gitlab.com/core-team/ do not work for GitLab the company.
Why do you think that? The non GitLab employees in the core team want to see a great and successful open source product and that is what is happening. The code they contribute stays open source. Ask them how they feel about it, I would be surprised if they would feel the company unfairly appropriates their work. Do you think Open Core can work if done right or do you think it always is a bad thing?
It is a downside but you can avoid it by not looking at the EE code you plan to contribute. Looking at the EE code is optional, it won't be needed to contribute to CE. The GitLab company will solve any merge conflicts that arise.
I responded to Sephr's comment. We think the open source project is better because of our open core business model. More than 80% of the company development efforts go into open source code. Many people contribute new features, but the work to make installation easy, release management, fixing bugs and performance regressions, investigating security reports and updating dependencies is for the most part done by GitLab the company. I recognize that the open core model requires a careful balance. But I think it is working very well for GitLab and is one of the reasons GitLab became more popular than the 100% open source alternatives.
While I am not against rapid UI evolution, as seems to be the case with GitLab, I think you may want to revise the choice of background vs text colour on the sidebar. It does look pretty, but the WCAG guidelines describe a minimum level of contrast for people with vision imparement to be able to read well. This side bar has a very low level of contrast, and putting the URL of a GitLab project into various WCAG evaluatioin tools will tell you the same.
Having said that, thank you for GitLab. Even though this post is about the Enterprise Edition, it is good to see some high quality open source alternatives to GitHub (i.e. the Community Version). We moved F-Droid there and have had mostly a very positive experience.
Thanks for moving F-Droid to GitLab.com, we appreciate it. You can change the colors of the sidebar on /profile/design I'm not sure if any other choices improve the contrast. Feel free to submit a design that meets WCAG guidelines.
Awesome! I really like using Gitlab CE. Are there any plans for more code review type enhancements? We typically do lots of discussion on merge requests and often times, certain code features or plans will get scheduled for a refactor sometime in the future. Though, all those comments kinda get hidden away after the branch is merged. Maybe what I should be doing is using the Wiki, but it would be nice to be able to leave comments on the HEAD (i.e. comments on current state of a project).
Good to hear you like GitLab. We don't have any plans for code review improvements at the moment. Your proposal sounds interesting. We normally try to refactor the code before merging the merge request. If there are any loose ends we make an issue out of it.
Something I consider for quite a while: Would it be possible to use GitLab as a 'frontend' only? With remote repositories?
I ask, because our company recently killed of a Gitorious instance that worked fine for ~5 years, to 'upgrade' us to TFS and there are quite some .. issues and limitations with that idea. Looking for a way to make IT happy ('yes, code is stored in TFS') and keep a usable/productive environment.
Frankly, I'm torn and might spin up a test instance on Monday (it's a day off here) to give it a try. Can't do jack about TFS hosting the sources, but anything that gives me a saner/better interface and usable issues etc. on top would be .. awesome.
Lovely! Congrats Sytse, Dimitry and co! Will be upgrading next week.
As a long time user (nearly 3 years now), it really is amazing that you guys manage to release dead on the 22nd EVERY month and always with new features! Amazing.
