Delay between a release (minor release with security fixes) and Docker images available on hub

[dgonzalez]

This delay can allow attackers to exploit a vulnerability in node core on Docker based systems. Last time I remember there was a delay of 1 day (which is not a lot) but still has to be considered as an attack vector.

[lirantal]

I'm not aware of the delay times but I agree if this is indeed the issue.
I believe this falls under the scope of the core nodejs/security team as this relates to job setup and such. Should we ping nodejs code security for more info on this?

[dgonzalez]

I will. Leave it with me.

…

On 20 Mar 2018 22:08, "Liran Tal" ***@***.***> wrote: I'm not aware of the delay times but I agree if this is indeed the issue. I believe this falls under the scope of the core nodejs/security team as this relates to job setup and such. Should we ping nodejs code security for more info on this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHkOsljOMPFdrd3qrKp0a_zJGdd_3qCks5tgX3vgaJpZM4SyQap> .

[mhdawson]

I think it will also involve the @nodejs/docker team as they do the updates which trigger new docker images to be built. It may be that they need to be part of the security release process so that the commits can be landed as soon as possible after the releases are available.

[Starefossen]

New versions for Official Docker Images needs to go through approval with Docker Inc. hence the 12-24h delay.

[PeterDaveHello]

@Starefossen is right, most of the update processes in the docker-node repository go fast, but we'll need the approval with Docker in the official-images repository, so it'll be a delay.

Another issue is that the members of @nodejs/docker have no control of our Travis CI, thus we can't stop the invalid or useless builds, and it takes a while to finish the all the CI tasks, that's also the part maybe we could improve.

[SimenB]

Sorta related: nodejs/node#14190

Getting a new version into master of docker-node as quickly as possible (and PRing docker hub), maybe even coordinating with the docker hub folks to have them ready to start the merging process beforehand, would be really good, I think.

[dgonzalez]

So, what about for security releases holding the main release for another 12-24 hours till docker is ready? If there is no disclosure of the vuln it is ok-ish. The world is moving towards Docker and we need to think of an scenario where 90% of users will be Docker based.

…

On 22 March 2018 at 08:00, Simen Bekkhus ***@***.***> wrote: Sorta related: nodejs/node#14190 <nodejs/node#14190> Getting a new version into master of docker-node as quickly as possible, maybe even coordinating with the docker hub folks to have them ready to start the merging process beforehabd, would be really good, I think. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHkOl7-dQi5H2pEr70jkvDkKC3lh-Blks5tg1oOgaJpZM4SyQap> .

[pesho]

@dgonzalez Holding the main release won't work currently, because official Docker images are built from public sources by design. So anyone can see which release tarball is used and access it.

Delaying disclosure of the actual vulnerabilities is a good idea though.

[LaurentGoderre]

Having a binary for alpine would also help speed up the updating of docker images but there isn't a consensus on this ATM.

nodejs/build#75

[dgonzalez]

@pesho and what about prepare the build on a private repository and at the moment of release PR into the repo and build it?

I am also ok on the delaying disclosure. I am a big fan on disclosing as early as possible but 12-24 hours won't make a huge difference. Said that, the commit history will surely show what was fixed and an avid hacker can use it as an attack vector.

[pesho]

@pesho and what about prepare the build on a private repository and at the moment of release PR into the repo and build it?

This will help a bit, but not enough. The Travis build will still take about 40 minutes (due to having to build for Alpine), and then it still must be submitted to Docker Inc. and wait for their separate review and approval.

[mhdawson]

There was feedback in the Enterprise user-feedback session today that this does cause anxiety for them. The feedback is that when we say you need up update quickly that activates processes in the and then they are under pressure while they have to wait a day for the release.

@Starefossen do we have any contacts at docker that we would talk to about the review delay for security releases? I can understand that for normal releases but I wonder if there is some way we can expedite by giving them advance notice of when a release will be coming.

[SimenB]

There is a process where, if a PR is tagged with "[Security release]" in the title, it will be prioritised by the Docker team. But I'm not sure how formal that process is, or what, if any, guarantees are given about response time.

@tianon and/or @yosifkit might be able to weigh in on this?

[chorrell]

We're also dealing with timezone differences.