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?
- 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.
They are also churning at a pretty insane rate due their release schedule. I did a very basic analysis of their repos at
And this is the churn for this month in their master and 8-7-stable branch
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.
- 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
As with any software project; there will be bugs.
As with any open source project; there will be eyes on the code.
The following versions are affected:
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
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.
EDIT: Or, indeed, that security patches should be delayed at all.
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. : )
Pretty common for security patches to take place out of hours