31–40 of 45 posts
No details, just like the posts about this yesterday. Obligatory 'check our blog later for more.'
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.
- 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
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 compa…
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…
No details, just like the posts about this yesterday. Obligatory 'check our blog later for more.'
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.
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.
As with any software project; there will be bugs.
As with any open source project; there will be eyes on the code.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.