GitLab Major Security Update for CVE-2016-4340
11–20 of 45 posts
Re: GitLab Major Security Update for CVE-2016-4340
#12[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?
Re: GitLab Major Security Update for CVE-2016-4340
#13Earlier quoted context omitted.
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.
Re: GitLab Major Security Update for CVE-2016-4340
#14Why 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…
Re: GitLab Major Security Update for CVE-2016-4340
#15Why 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…
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.
Re: GitLab Major Security Update for CVE-2016-4340
#16Earlier quoted context omitted.
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.
Re: GitLab Major Security Update for CVE-2016-4340
#17Earlier quoted context omitted.
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.
The Dockerfile is displayed for the manual builds. What other visibility are you missing?
Re: GitLab Major Security Update for CVE-2016-4340
#18Earlier quoted context omitted.
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.
Re: GitLab Major Security Update for CVE-2016-4340
#19Earlier quoted context omitted.
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.
Re: GitLab Major Security Update for CVE-2016-4340
#20Earlier quoted context omitted.
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.
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. : )