
GitLab Major Security Update for CVE-2016-4340 - stenius
https://about.gitlab.com/2016/04/28/gitlab-major-security-update-for-cve-2016-4340/
======
dperfect
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/](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?

~~~
jarfil
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.

~~~
dperfect
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.

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

~~~
dperfect
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.

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

------
angerman
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.

~~~
sdesol
> 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](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](http://imgur.com/PfyFrzS)

I also included the
[https://github.com/atom/atom](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.

~~~
Sephr
Did you delete [http://imgur.com/PfyFrzS](http://imgur.com/PfyFrzS) ?

~~~
sdesol
Yeah it had some inaccuracies.

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

~~~
jrochkind1
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.

~~~
mkj
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.

~~~
jrochkind1
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.

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

~~~
gburt
Yes.

------
hijinks
why do they release it at 5pm PDT? A lot of people are leaving work on the
west coast. The rest of the country people are home eating dinner. EU is
sleeping. Really stupid time.

~~~
Jedd
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.

~~~
iancarroll
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.

~~~
Jedd
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. : )

