Critical Security Release for GitLab 8.2 through 8.7 • Hacker News Board

Re: Critical Security Release for GitLab 8.2 through 8.7

#31

Post by daxelrod » Tue, May 03, 2016, 1:14 PM UTC

kentonv wrote: post #11

Gitlab can be run on Sandstorm.io (of which I am tech lead / co-founder). Sandstorm claims to mitigate most vulnerabilities in apps: https://docs.sandstorm.io/en/latest/using/security-non-event... Let's see how it scores here... For background, on Sandstorm, each Gitlab project is placed in a separate grain (container), isolated from all others. In order to communicate with a grain at all, you must have been granted…

Since every project is isolated, how do you handle operations that require data from multiple projects, such as the activity feed or merge requests?

I'm also curious, how extensively do you need to modify GitLab for Sandstorm? Is that https://github.com/dwrensha/gitlab-sandstorm ?

Re: Critical Security Release for GitLab 8.2 through 8.7

#32

Post by kentonv » Tue, May 03, 2016, 5:06 PM UTC

corobo wrote: post #21

mserdarsanli wrote: post #17

Earlier quoted context omitted.

From https://sandstorm.io/install > Run this in a terminal: > curl https://install.sandstorm.io | bash kthxbye

and then you read on into the next few lines for "Wondering what this script will do? [Watch this 30 second screencast] or [read the install documentation]. If you prefer more validation, you can [download the install script from GitHub] or [build from source]." I do get the point you're trying to make but as far as 'curl|bash' installations go these guys at least seem be doing it as right as they can

Or you look to the right and click on "PGP verified install". :)

Re: Critical Security Release for GitLab 8.2 through 8.7

#33

Post by kentonv » Tue, May 03, 2016, 6:04 PM UTC

daxelrod wrote: post #31

kentonv wrote: post #11

Gitlab can be run on Sandstorm.io (of which I am tech lead / co-founder). Sandstorm claims to mitigate most vulnerabilities in apps: https://docs.sandstorm.io/en/latest/using/security-non-event... Let's see how it scores here... For background, on Sandstorm, each Gitlab project is placed in a separate grain (container), isolated from all others. In order to communicate with a grain at all, you must have been granted…

Since every project is isolated, how do you handle operations that require data from multiple projects, such as the activity feed or merge requests? I'm also curious, how extensively do you need to modify GitLab for Sandstorm? Is that https://github.com/dwrensha/gitlab-sandstorm ?

> Since every project is isolated, how do you handle operations that require data from multiple projects, such as the activity feed or merge requests?

Right now: Poorly.

But in a few months: - We're adding an activity feed API to Sandstorm, so that you can get a unified feed and notifications across all apps. - The Powerbox (https://sandstorm.io/how-it-works#powerbox) allows connecting grains to each other. We will define a git API which each of the git apps (Gitlab, Gitweb, Gogs) can implement, so that you can even do cross-app merge requests.

Re: Critical Security Release for GitLab 8.2 through 8.7

#34

Post by kentonv » Tue, May 03, 2016, 7:38 PM UTC

kogepathic wrote: post #25

zackp30 wrote: post #24

Earlier quoted context omitted.

No need for the rudeness. I always get bothered when people bring up the `curl [...] | bash` “argument” (which is usually less of an argument and more of a rude dismissal of a good product). Sure, the script downloaded with curl should be validated. Not sure, but I’m pretty sure you don’t validate every tarball you download, and even if you do validate them, you certainly wouldn’t look through each line of code makin…

> I always get bothered when people bring up the `curl [...] | bash` “argument” (which is usually less of an argument and more of a rude dismissal of a good product). Why? Package managers were created for a reason. Virtually every Linux distribution anyone would use to host a service such as Sandstorm will include a package manager. > Not sure, but I’m pretty sure you don’t validate every tarball you download, and e…

> Virtually every Linux distribution anyone would use to host a service such as Sandstorm will include a package manager.

Yes, but:

* Most of them ship on a 6-month or even 2-year release cycle whereas Sandstorm updates every week.

* Most of them will not accept a package that wants to self-containerize with its own dependencies, which means Sandstorm would instead have to test against every different distro's dependency packages every week, whereas with self-containerization we only depend on the Linux kernel API -- which is insanely stable.

* If we publish the packages from our own repo, we're back to square one: how does the user get the signing key, if not from HTTPS download?

* Sandstorm actually has a PGP-verified install option: https://docs.sandstorm.io/en/latest/install/#option-3-pgp-ve...

* You should probably be installing Sandstorm in its own VM anyway.

I'm certainly not saying curl|bash is perfect. There are trade-offs. For now this is the trade-off that makes the most sense for us. Later on, maybe something else will make sense.

> If they think that will ever be acceptable in an enterprise environment where change management is important, they're delusional.

We've never had an enterprise customer comment on this (other than requesting the PGP-verified option, which we implemented). The vast majority of complaints come from HN, Twitter, and Reddit. ::shrug::

Re: Critical Security Release for GitLab 8.2 through 8.7

#35

Post by sdesol » Tue, May 03, 2016, 7:45 PM UTC

StavrosK wrote: post #28

sdesol wrote: post #27

Earlier quoted context omitted.

Since we are doing deja vu, I uploaded some new metrics that better highlights how insane GitLab's churn rate is. http://imgur.com/a/4uaSR What's really interesting is the number of contributors.

What does this show, exactly? I'm not familiar with this tool and there are no labels.

It basically shows how much has changed in GitLab's master branch in the last 30 days. The main metrics is cumulative code churn (lines added, changed, and deleted that does not involve comment or blank lines).

In the first picture it shows the churn was about 24,000 if you don't include merge commits (nomerge:true) and if you ignore changes that were the result of adding/deleting files (action:M).

The numbers with the avatars are basically. First column is number of commits. Second column is cumulative code churn. Third column is percentage of churn that does not involve blank/comment lines.

The second and third pictures shows the code churn as grouped by top level directories. In GitLab's case the most churn occurred in the app directory. And if you drill down to app/assets/javascripts, you'll see the following:

http://imgur.com/B2GE1yk

The charts and metrics basically shows GitLab's code base is changing a lot. This is the churn for Gogs in the last 30 days.

http://imgur.com/ZmzyMsz

And I guess the question is, is the high rate of change a contributing factor for increased security issues? Statistically speaking, the more code, the more chances for something being missed during code reviews.

It's important to note the metrics isn't saying the quality is bad. It's just saying a lot is changing.

Re: Critical Security Release for GitLab 8.2 through 8.7

#36

Post by kogepathic » Tue, May 03, 2016, 8:01 PM UTC

kentonv wrote: post #34

kogepathic wrote: post #25

Earlier quoted context omitted.

> I always get bothered when people bring up the `curl [...] | bash` “argument” (which is usually less of an argument and more of a rude dismissal of a good product). Why? Package managers were created for a reason. Virtually every Linux distribution anyone would use to host a service such as Sandstorm will include a package manager. > Not sure, but I’m pretty sure you don’t validate every tarball you download, and e…

> Virtually every Linux distribution anyone would use to host a service such as Sandstorm will include a package manager. Yes, but: * Most of them ship on a 6-month or even 2-year release cycle whereas Sandstorm updates every week. * Most of them will not accept a package that wants to self-containerize with its own dependencies, which means Sandstorm would instead have to test against every different distro's depend…

> Most of them ship on a 6-month or even 2-year release cycle whereas Sandstorm updates every week.

That's fine. Run your own repo where you control the release cycle. Puppet does this. GitLab does this. PostgreSQL does this. Sandstorm does not do this.

> Most of them will not accept a package that wants to self-containerize with its own dependencies, which means Sandstorm would instead have to test against every different distro's dependency packages every week, whereas with self-containerization we only depend on the Linux kernel API -- which is insanely stable.

GitLab ships an omnibus installer with their CE/EE product, and it works great. I don't see why Sandstorm couldn't also publish an omnibus installer which contains all the dependencies, in essence creating your own container in somewhere neutral like /opt

This way, you have atomic releases you can install. How do I select the version to install with 'curl | bash' without user interaction?

> If we publish the packages from our own repo, we're back to square one: how does the user get the signing key, if not from HTTPS download?

Publish your signing key as a distribution package. This is what most organizations do (e.g. EPEL, PostgreSQL, Puppet).

Then the user does 'apt-get install sandstorm-release', 'apt-get update', 'apt-get install sandstorm' and you have an authenticated release.

Your signing infrastructure should be secure enough that you don't have to change the signing key within the major release cycle of a Linux distribution anyway.

> You should probably be installing Sandstorm in its own VM anyway.

This isn't an excuse for 'curl | bash' installs. If they want to recommend that their customers run the product in a VM or container, they should provide appliance/container images, as well as packages.

> We've never had an enterprise customer comment on this

I am in enterprise, although I'm not a sandstorm customer. I will tell you that one of the first considerations when deciding on a product is how well it fits into our existing infrastructure. If I can't push a repo and install a specific version of the software, tested and known working, using puppet, it's not getting deployed in our org.

Perhaps the reason none of Sandstorm's enterprise customers are asking for packaged installers is because every enterprise customer who expects a packaged installer sees Sandstorm's installation method and decides not to use it.

Re: Critical Security Release for GitLab 8.2 through 8.7

#37

Post by sytse » Tue, May 03, 2016, 8:41 PM UTC

sdesol wrote: post #35

StavrosK wrote: post #28

Earlier quoted context omitted.

What does this show, exactly? I'm not familiar with this tool and there are no labels.

It basically shows how much has changed in GitLab's master branch in the last 30 days. The main metrics is cumulative code churn (lines added, changed, and deleted that does not involve comment or blank lines). In the first picture it shows the churn was about 24,000 if you don't include merge commits (nomerge:true) and if you ignore changes that were the result of adding/deleting files (action:M). The numbers with t…

A lot is changing since GitLab is rapidly developing. If you have more churn with the same amount of developers that might lead to increased security issues. We've been quickly adding paid developers over the last year, so I'm not sure what that ratio did. Also, some of the churn is due to refactorings, although these are risky in themselves over the long run they increase code quality.