Date
1 - 6 of 6
Cloud Foundry NodeJS 4 support and release schedule
Mike Dalessio
Quick update on Node 4, which is that we're blocked on openssl
compatibility.
One of the requirements we place on binaries we ship with CF buildpacks is
that libraries should be dynamically linked from the rootfs whenever
possible, particularly for libraries that are likely to be affected by
CVEs, so that we can patch everything with a rootfs update.
Node has defaulted, for quite a while, to statically linking OpenSSL,
despite a history of not-infrequent CVEs affecting that library. The Node
build scripts do allow overriding this, and choosing to dynamically link
instead. We've used this option successfully for building all of the
CF-supported 0.x node versions against the openssl 1.0.1 versions that are
shipped with Ubuntu 14.04 LTS (and therefore the cflinuxfs2 rootfs).
However, in Node 4, the code only supports openssl 1.0.2. That is, it fails
to compile against openssl 1.0.1 headers.
(Possibly worth mentioning for additional context, even RHEL7 appears to
still ship openssl 1.0.1.)
We opened a Github issue on the node project, which has been closed without
a suggested fix for our situation:
https://github.com/nodejs/node/issues/2783
We've also reached out to friends of the CFF at Joyent, and IBM has notably
reached out to their own Node committers on staff. I'll keep this thread
updated as the conversation progresses.
I'm not comfortable introducing a new binary to the CF ecosystem that's not
"patch-able" via a rootfs update. I'm open to suggestions around what else
we could be doing to move towards shipping Node 4, but for right now we're
blocked.
-m
toggle quoted message
Show quoted text
compatibility.
One of the requirements we place on binaries we ship with CF buildpacks is
that libraries should be dynamically linked from the rootfs whenever
possible, particularly for libraries that are likely to be affected by
CVEs, so that we can patch everything with a rootfs update.
Node has defaulted, for quite a while, to statically linking OpenSSL,
despite a history of not-infrequent CVEs affecting that library. The Node
build scripts do allow overriding this, and choosing to dynamically link
instead. We've used this option successfully for building all of the
CF-supported 0.x node versions against the openssl 1.0.1 versions that are
shipped with Ubuntu 14.04 LTS (and therefore the cflinuxfs2 rootfs).
However, in Node 4, the code only supports openssl 1.0.2. That is, it fails
to compile against openssl 1.0.1 headers.
(Possibly worth mentioning for additional context, even RHEL7 appears to
still ship openssl 1.0.1.)
We opened a Github issue on the node project, which has been closed without
a suggested fix for our situation:
https://github.com/nodejs/node/issues/2783
We've also reached out to friends of the CFF at Joyent, and IBM has notably
reached out to their own Node committers on staff. I'll keep this thread
updated as the conversation progresses.
I'm not comfortable introducing a new binary to the CF ecosystem that's not
"patch-able" via a rootfs update. I'm open to suggestions around what else
we could be doing to move towards shipping Node 4, but for right now we're
blocked.
-m
On Wed, Sep 9, 2015 at 3:52 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:
Thanks for the quick feedback on this, we appreciate your responsiveness.
We'll continue to follow the issue in the pivotal tracker.
On Wed, Sep 9, 2015 at 12:36 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:Hi Shawn,
Great question, thanks for asking it.
The Buildpacks team has a Tracker story in its backlog to work on Node 4:
https://www.pivotaltracker.com/story/show/102941608
Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.
The story I linked to has some specific acceptance criteria:
* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.
Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.
Additionally I'll likely delay committing it into cf-release until we
have positive feedback from the community.
I'm happy to keep this thread updated with our progress; or you can
follow along at the Tracker story.
Cheers,
-mike
On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com>
wrote:NodeJS version 4 was released yesterday to the community.
Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?
More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.
Shawn Nielsen
Thanks for the quick feedback on this, we appreciate your responsiveness.
We'll continue to follow the issue in the pivotal tracker.
toggle quoted message
Show quoted text
We'll continue to follow the issue in the pivotal tracker.
On Wed, Sep 9, 2015 at 12:36 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Hi Shawn,
Great question, thanks for asking it.
The Buildpacks team has a Tracker story in its backlog to work on Node 4:
https://www.pivotaltracker.com/story/show/102941608
Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.
The story I linked to has some specific acceptance criteria:
* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.
Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.
Additionally I'll likely delay committing it into cf-release until we have
positive feedback from the community.
I'm happy to keep this thread updated with our progress; or you can follow
along at the Tracker story.
Cheers,
-mike
On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com> wrote:NodeJS version 4 was released yesterday to the community.
Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?
More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.
Mike Dalessio
Hi Shawn,
Great question, thanks for asking it.
The Buildpacks team has a Tracker story in its backlog to work on Node 4:
https://www.pivotaltracker.com/story/show/102941608
Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.
The story I linked to has some specific acceptance criteria:
* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.
Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.
Additionally I'll likely delay committing it into cf-release until we have
positive feedback from the community.
I'm happy to keep this thread updated with our progress; or you can follow
along at the Tracker story.
Cheers,
-mike
toggle quoted message
Show quoted text
Great question, thanks for asking it.
The Buildpacks team has a Tracker story in its backlog to work on Node 4:
https://www.pivotaltracker.com/story/show/102941608
Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.
The story I linked to has some specific acceptance criteria:
* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.
Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.
Additionally I'll likely delay committing it into cf-release until we have
positive feedback from the community.
I'm happy to keep this thread updated with our progress; or you can follow
along at the Tracker story.
Cheers,
-mike
On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com> wrote:
NodeJS version 4 was released yesterday to the community.
Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?
More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.
James Thomas <jthomas.uk@...>
I was playing around this morning using the Heroku Node.js binaries for v4
with the existing CF Node.js buildpack.
https://github.com/jthomas/nodejs-v4-buildpack/commit/e2b6887638af1be2e472f989b3d005a0e33fb787
It worked perfectly with my test app.
On 9 September 2015 at 17:16, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:
--
Regards,
James Thomas
with the existing CF Node.js buildpack.
https://github.com/jthomas/nodejs-v4-buildpack/commit/e2b6887638af1be2e472f989b3d005a0e33fb787
It worked perfectly with my test app.
On 9 September 2015 at 17:16, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:
Nice news!
In my side, I am working on a Node Client for Cloud foundry:
https://github.com/jabrena/cf-nodejs-client
and a webApp to deploy in a easy way applications:
https://github.com/prosociallearnEU/cf-nodejs-dashboard
Regards
Juan Antonio
--
Regards,
James Thomas
Juan Antonio Breña Moral <bren at juanantonio.info...>
Nice news!
In my side, I am working on a Node Client for Cloud foundry:
https://github.com/jabrena/cf-nodejs-client
and a webApp to deploy in a easy way applications:
https://github.com/prosociallearnEU/cf-nodejs-dashboard
Regards
Juan Antonio
In my side, I am working on a Node Client for Cloud foundry:
https://github.com/jabrena/cf-nodejs-client
and a webApp to deploy in a easy way applications:
https://github.com/prosociallearnEU/cf-nodejs-dashboard
Regards
Juan Antonio
Shawn Nielsen
NodeJS version 4 was released yesterday to the community.
Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?
More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.
Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?
More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.