Why is the latest official GitLab CE docker image 7 months old[1]? Is that no longer a recommended install method?

[1] https://hub.docker.com/r/gitlab/gitlab-ce/builds/

EDIT: Maybe I'm looking in the wrong place? The "latest builds" page shows activity from 7 months ago, but the "tags" page is showing "latest" updated 6 days ago. Does that just refer to the source repo tag, or a successful build that (for some reason) doesn't show in the builds page?

The "latest builds" page shows automated builds created by docker hub, but repo owners can also manually push builds created by themselves, which seems to be the case.

Ah, that makes sense - thanks. Looks like many (most?) of the most popular images on Docker Hub are as you say - manually-pushed builds. A part of me wishes that more of them were automated, just to have more visibility into what exactly goes into each image. I guess that's off-topic though.

Unfortunately automated builds on Docker Hub don't yet support GitLab.com, that is why we use a manual build.

The Dockerfile is displayed for the manual builds. What other visibility are you missing?

From what I understand, the source often contains other files/scripts that are invoked by the Dockerfile, so that would be one example of potentially missing visibility.

True, but even if the build is automated, you won't necessarily have access to the full source.

It feels to me as if GitLab is pushing (major) security updates very often. Now there are two reasons I can think of this happening:

- They are very open about security vulnerabilities and fix them fast.

- There are some inherent defects in their software that cause these security vulnerabilities to come up so frequently.

I'd like to believe it's the first.

EDIT: formatting.

> Now there are two reasons I can think of this happening

They are also churning at a pretty insane rate due their release schedule. I did a very basic analysis of their repos at

http://gitsense.github.io/blog/motion-bubble-charts.html

And this is the churn for this month in their master and 8-7-stable branch

http://imgur.com/PfyFrzS

I also included the https://github.com/atom/atom master branch (blue line) for comparison.

In order to get a better picture what what's going on, I'll need to cross reference the churn to security issues, but this isn't something my tool will support until later in the year.

Did you delete http://imgur.com/PfyFrzS ?

Yeah it had some inaccuracies.

Wow, this is super cool! Thanks for doing this!

I think it's because of a number of reasons:

- We're very open about vulnerabilities and fix them fast

- We have a large install base, in particular >100k Community Edition installations

- Our source code is open and not obfuscated. It's easier to mess around in it for anyone interested, even when it's running.

- We regularly have security researchers perform audits

- Our rate of change (as mentioned by others) is very high

You probably perceive GitLab as having more vulns because we're a very open company, whereas most other companies keep it mostly to themselves.

Relevant: https://twitter.com/tenderlove/status/725370404513017856

This question got picked up by InfoQ. See the reply of our VP of Engineering in http://www.infoq.com/news/2016/05/gitlab-impersonate-vulnera...

Only thing I can add to all the other reasons already mentioned is the most obvious one that gitlab has received a lot of press and exposure during the last 2 years and this in turn has made the number of eyes on the code grow.

As with any software project; there will be bugs.

As with any open source project; there will be eyes on the code.

Why not both?

No details, just like the posts about this yesterday. Obligatory 'check our blog later for more.'

That's pretty much the only way to do a security update for something people are going to want to patch asap. warn people in advance it's coming so they can be ready to apply when released, without giving away any details that might help someone find the exploit before it comes.

They could say what the exposure is. If it's just "your private repos are exposed" then it wouldn't be urgent to patch a public server, for example.

If they're not saying, I assume it's something really terrible. If it's not something really terrible, then all the advance notice advertising is perhaps cry-wolf overkill.

Let's hope it's not remote code execution on the CI daemons.

It would be nice to know what versions are affected now but I can understand that they may not want to reveal that until it's patched to prevent any unauthorized access of private repositories.

From an email they sent out two days ago:

  The following versions are affected:

    8.7.0
    8.6.0 through 8.6.7 
    8.5.0 through 8.5.11 
    8.4.0 through 8.4.9 
    8.3.0 through 8.3.8 
    8.2.0 through 8.2.4 

Not sure why this wasn't included here.

Is it a specific mailing list ? I didn't get anything.

IIRC it's the "Security Notices" list from https://about.gitlab.com/contact/

Is it just me or does the Security Notices not link anywhere? (Chrome)

I got it as standard user several hours ago.

Thank you mam/sir!* I should jump on that mailing list ASAP

There are not a lot of things at GitLab that we don't disclose if we have the option to be open about it. [0]

In this case, we can't disclose any more than we did so far.

We'll probably do a public post-mortem of the entire process once it's behind us.

[0]: https://about.gitlab.com/primer/

Yesterday there wasn't even an official post for 8+ hours after the mail to the mailing list. Great that gitlab notifies people about security issues and tries to fix them... but no points for transparency here

So just to clarify because its as clear as mud, 8.7 is still affected so we are waiting for an update ?

Yes.

Here in AU, we're not comfortable with the proposition that security alerts should be delayed until it's convenient for where $SOMEONE_ELSE happens to live.

EDIT: Or, indeed, that security patches should be delayed at all.

You shouldn't think of this as being delayed; they are providing advance notice of a serious vulnerability being patched so that those using it can update ASAP.

Agreed and understood.

I meant delayed in the sense that if a patch is available, and fixes anything other than a trivial problem, it should be released as soon as is practicable (appreciating that there may be dependencies they wish to synchronise with, or in this case, trying to mitigate the obvious risks associated with the immediate definition of the exploit). Obviously I'm not limiting myself to gitlab patches here.

Appreciate the heads-up - especially for people with an unfortunate combination of highly exposed systems and inconvenient timezones. : )

Its probably the most convenient window to minimise service disruption amongst users of gitlabs.

Pretty common for security patches to take place out of hours

Unless it creates a 'thundering herd', everyone downloading the update simultaneously, killing throughput.

Handling large volume of downloads of one static large package is in general a pretty solved problem.

(Unless you're Apple)

This is why torrents exist.