Hacker News Reader

Comment by beefhash | Hacker News Reader

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.

View on HN

Having worked in a large set of codebases as a consultant, I'm pretty sure it's the former. The code that runs the world is mostly garbage (the proprietary stuff that is, because they can hide it)

Similarly, never count on a compromise of your data to get reported unless local law absolutely requires it, and someone who cares notices. If your data was compromised in a way not covered by local law, companies will hide the compromise.

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.

Your comment is weirdly similar to this other comment that I saw in the initial announcement:

https://news.ycombinator.com/item?id=11593362

I had to check that it wasn't the same user. I know groupthink is a thing, but the cynic in me wondered if this comment wasn't an upvote grab.

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.

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.

Other commentor already nailed it I think. How many critical security issues do you think Github has had that you've never heard of? Not knocking Github, it's just the nature of extreme open source I think.

Github isn't open source.

But GitLab is and that's what the comment was about.

You should also factor in their software model. GitLab has a free install anyone can run locally without having to register. A competitor like GitHub has enterprise install but otherwise most public traffic is on their own hosted install. If there's a security issue they likely fix their hosted install and inform their enterprise customers only -- as well they probably shouldn't make it public otherwise it could be considered some level of exposure to their customers. Conversely GitLab essentially needs to publicize this to maintain the trust of their customers.

I think that makes them more trustworthy. If some open source software has never seen a CVE, then that is because no-one actually looked at it in depth enough. All software has bugs and security issues.

There are other reasons too. Once someone finds an issue in an open-source project, other people realise it's not super secure and start to dig deeper. Same thing happened with image decoders (libpng), asn1 parsers, syscalls fuzzing, digging into openssl, etc. Bugs in big products and common protocols come in waves.

Not been tracking GitLab closely but how many critical issues have there been in the last 6 months?

Reply on news.ycombinator.com