Live data from Hacker News

Critical Security Release for GitLab 8.2 through 8.7

about.gitlab.com

21–30 of 37 posts

Re: Critical Security Release for GitLab 8.2 through 8.7

#21
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…

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

Re: Critical Security Release for GitLab 8.2 through 8.7

#23
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…

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

At least it is https, so no mitm attack. You have to trust the Sandstorm developers, even if you download the source and apply all the steps manually. If the site gets compromised, the attackers can modify the source and the website documentation for the PGP verification.

Re: Critical Security Release for GitLab 8.2 through 8.7

#24
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…

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

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 making sure there isn’t a backdoor or something.

Any malicious person could break into a tarball download site, and replace the checksums as well (only way to mitigate that is using a signature that is associated with the tarball maintainer), and even if something like PGP is used, the attacker would be able to replace the instructions to obtain the PGP key with their own generated one, or even remove the signature completely.

This is, of course, the same for curl piped into bash, but my point is that it’s only slightly worse than an unsecured package site (which I’m sure there are many of). The only thing worse about it is that it’s less noticeable when the script has been replaced.

Also, some scripts (such as the rvm installatio script) /require/ PGP to be used for the installation to even start.

In conclusion, please don’t be rude and dismiss an entire product because of a single installation method, which isn’t actually worse than a malicious tarball.

Re: Critical Security Release for GitLab 8.2 through 8.7

#25
post #24

Earlier quoted context omitted.

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

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 even if you do validate them, you certainly wouldn’t look through each line of code making sure there isn’t a backdoor or something.

I don't download tarballs. I install packages. Who downloads tarballs to install software in 2016?

Anyone actively developing for a project will likely be using git, and I'm not aware of too many projects which make use of toolchains which are so new that they're not available in any rolling release/testing distro.

> Any malicious person could break into a tarball download site, and replace the checksums as well (only way to mitigate that is using a signature that is associated with the tarball maintainer), and even if something like PGP is used, the attacker would be able to replace the instructions to obtain the PGP key with their own generated one, or even remove the signature completely.

Yes, fine. And that's why all major distributions sign their packages, so you know that it's valid. Again, it's 2016, who seriously installs software from tarballs?

> The only thing worse about it is that it’s less noticeable when the script has been replaced.

No, what is much worse than that is you are installing software outside of your package manager. Also, companies who deploy via curl | bash, typically pull in their own dependencies outside of the package manager.

It's bad form.

If your application has specific dependencies, then ship it as an appliance using LXC, Docker, or $TRENDY_CONTAINER_TECH. That way, all updates are atomic and you don't risk eff-ing the OS by pulling in a bunch of stuff outside of the package manager.

> In conclusion, please don’t be rude and dismiss an entire product because of a single installation method, which isn’t actually worse than a malicious tarball.

In conclusion, package management is a solved problem. Companies which have installers which do not make use of the distribution's package management system are lazy, and anyone who defends curl | bash is an apologist.

Seriously, it's not difficult to generate a DEB/RPM/ and create your own signed repo. Package management has been a solved problem for at least a decade.

It annoys me that companies think it's okay to have curl | bash as an installation method. If they think that will ever be acceptable in an enterprise environment where change management is important, they're delusional.

Re: Critical Security Release for GitLab 8.2 through 8.7

#26
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…

All good points. Thanks!

I agree that all companies should have a signed package repository, instead of tarballs 100%.

I didn't mean to defend ‘curl | bash‘, I just meant to say why ‘curl | bash‘ isn’t as bad as people think (versus tarballs). Package managers definitely are far superior to tarballs, and ‘curl | bash‘.

Another thing I didn’t like is how the OP seemingly dismissed an entire product with the single statement “kthxbai”, but that’s not relevant.

In an ideal world companies (or even small projects) have repositories, in an even more ideal world they were in the distro repositories already.

Re: Critical Security Release for GitLab 8.2 through 8.7

#27
post #2

Is it just me or has gitlab issued a lot of critical security releases lately? I'm not sure if this is because they're particularly open about these things or because their product might be particularly insecure.

Your comment is weirdly similar to this other comment that I saw in the initial announcement: https://news.ycombinator.com/item?id=11593362

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.

Re: Critical Security Release for GitLab 8.2 through 8.7

#28
post #27

Earlier quoted context omitted.

Your comment is weirdly similar to this other comment that I saw in the initial announcement: https://news.ycombinator.com/item?id=11593362

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.

Re: Critical Security Release for GitLab 8.2 through 8.7

#29
post #2

Is it just me or has gitlab issued a lot of critical security releases lately? I'm not sure if this is because they're particularly open about these things or because their product might be particularly insecure.

Finding, fixing, and openly discussing software issues makes me more confident in GitLab, not less. I see this as a positive thing.

Thanks! We're working on a postmortem blog post about our process for releasing these fixes.

Re: Critical Security Release for GitLab 8.2 through 8.7

#30
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…

Thanks Kenton, very interesting. And thanks for supporting GitLab on Sandstorm.
Post reply on HN