7 ms·

GitLab Major Security Update for CVE-2016-4340

91 points by stenius 10y ago

hijinks 10y ago
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.
- wyaeld 10y ago
  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
  - peter_tonoli 10y ago
    Unless it creates a 'thundering herd', everyone downloading the update simultaneously, killing throughput.
    - jrochkind1 10y ago
      Handling large volume of downloads of one static large package is in general a pretty solved problem.
      - breakingcups 10y ago
        (Unless you're Apple)
    - kpcyrd 10y ago
      This is why torrents exist.
- Jedd 10y ago
  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 10y ago
    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 10y ago
      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. : )
  - engiqueer 10y ago
    Remind me where AU is again??
paraxisi 10y ago
No details, just like the posts about this yesterday. Obligatory 'check our blog later for more.'
- puddintane 10y ago
  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.
  - pfg 10y ago
    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.
    - markwakeford 10y ago
      Is it a specific mailing list ? I didn't get anything.
      - pfg 10y ago
        IIRC it's the "Security Notices" list from https://about.gitlab.com/contact/ https://about.gitlab.com/contact/
        eadz 10y ago
        Is it just me or does the Security Notices not link anywhere? (Chrome)
      - mynewtb 10y ago
        I got it as standard user several hours ago.
    - puddintane 10y ago
markwakeford 10y ago
So just to clarify because its as clear as mud, 8.7 is still affected so we are waiting for an update ?
- gburt 10y ago
  Yes.
dperfect 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      The Dockerfile is displayed for the manual builds. What other visibility are you missing?
      - dperfect 10y ago
        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 10y ago
        True, but even if the build is automated, you won't necessarily have access to the full source.
angerman 10y ago
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.
- fabulist 10y ago
  Why not both?
- sdesol 10y ago
  > 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.
  - jobvandervoort 10y ago
    Wow, this is super cool! Thanks for doing this!
  - Sephr 10y ago
    Did you delete http://imgur.com/PfyFrzS http://imgur.com/PfyFrzS ?
    - sdesol 10y ago
      Yeah it had some inaccuracies.
- connorshea 10y ago

91 points by stenius 10y ago

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.

wyaeld 10y ago
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
- peter_tonoli 10y ago
  Unless it creates a 'thundering herd', everyone downloading the update simultaneously, killing throughput.
  - jrochkind1 10y ago
    Handling large volume of downloads of one static large package is in general a pretty solved problem.
    - breakingcups 10y ago
      (Unless you're Apple)
  - kpcyrd 10y ago
    This is why torrents exist.
Jedd 10y ago
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 10y ago
  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 10y ago
    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. : )
- engiqueer 10y ago
  Remind me where AU is again??

paraxisi 10y ago

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

puddintane 10y ago
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.
- pfg 10y ago
  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.
  - markwakeford 10y ago
    Is it a specific mailing list ? I didn't get anything.
    - pfg 10y ago
      IIRC it's the "Security Notices" list from https://about.gitlab.com/contact/ https://about.gitlab.com/contact/
      - eadz 10y ago
        Is it just me or does the Security Notices not link anywhere? (Chrome)
    - mynewtb 10y ago
      I got it as standard user several hours ago.
  - puddintane 10y ago

markwakeford 10y ago

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

gburt 10y ago
Yes.

dperfect 10y ago

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 10y ago
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 10y ago
  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 10y ago
    The Dockerfile is displayed for the manual builds. What other visibility are you missing?
    - dperfect 10y ago
      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 10y ago
        True, but even if the build is automated, you won't necessarily have access to the full source.

angerman 10y ago

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.

fabulist 10y ago
Why not both?
sdesol 10y ago
> 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.
- jobvandervoort 10y ago
  Wow, this is super cool! Thanks for doing this!
- Sephr 10y ago
  Did you delete http://imgur.com/PfyFrzS http://imgur.com/PfyFrzS ?
  - sdesol 10y ago
    Yeah it had some inaccuracies.
connorshea 10y ago