Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well Also need feedback from users.
I hope I didn't forget anything important.
Regards
Zuzka Node.js SIG
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
Also need feedback from users.
I hope I didn't forget anything important.
Regards
Zuzka Node.js SIG
On 11 August 2016 at 07:43, Stephen Gallagher sgallagh@redhat.com wrote:
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
How will the packages be named? Are we doing this as nodejs6 or nodejs?
Unless we decide to go the "both lts versions" path, I'd update nodejs. I see no point in having packages, that are unmaintained by upstream, in the repo.
----- Original Message ----- From: "Stephen John Smoogen" smooge@gmail.com To: "EPEL Development List" epel-devel@lists.fedoraproject.org Cc: "Zuzana Svetlikova" zsvetlik@redhat.com, epel-devel-list@redhat.com, epel-devel@fedoraproject.org Sent: Thursday, August 11, 2016 6:11:14 PM Subject: Re: [EPEL-devel] Re: nodejs update
On 11 August 2016 at 07:43, Stephen Gallagher sgallagh@redhat.com wrote:
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
How will the packages be named? Are we doing this as nodejs6 or nodejs?
On 12 August 2016 at 04:04, Zuzana Svetlikova zsvetlik@redhat.com wrote:
Unless we decide to go the "both lts versions" path, I'd update nodejs. I see no point in having packages, that are unmaintained by upstream, in the repo.
No problem. I am just wanting to get the correct picture of the plan in my head .
----- Original Message ----- From: "Stephen John Smoogen" smooge@gmail.com To: "EPEL Development List" epel-devel@lists.fedoraproject.org Cc: "Zuzana Svetlikova" zsvetlik@redhat.com, epel-devel-list@redhat.com, epel-devel@fedoraproject.org Sent: Thursday, August 11, 2016 6:11:14 PM Subject: Re: [EPEL-devel] Re: nodejs update
On 11 August 2016 at 07:43, Stephen Gallagher sgallagh@redhat.com wrote:
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
How will the packages be named? Are we doing this as nodejs6 or nodejs?
-- Stephen J Smoogen.
On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
* We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana?
* Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2 and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side tag to build it into. Will make it easier so you don't need to deal with a billion build overrides etc.
Peter
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
- We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly
requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana?
- Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o...
On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side tag to build it into. Will make it easier so you don't need to deal with a billion build overrides etc.
I'm not sure that will be strictly necessary; we figured out during the Fedora process that once we moved to the bundled NPM, we only had about a dozen packages that actually needed a rebuild to support Node.js 6.x (just the ones that build a native, archful module).
But yes, I'll make sure to let you know if we decide it needs a side-tag.
On 23/08/16 03:48, Stephen Gallagher wrote:
On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side tag to build it into. Will make it easier so you don't need to deal with a billion build overrides etc.
I'm not sure that will be strictly necessary; we figured out during the Fedora process that once we moved to the bundled NPM, we only had about a dozen packages that actually needed a rebuild to support Node.js 6.x (just the ones that build a native, archful module).
But yes, I'll make sure to let you know if we decide it needs a side-tag.
Nodejs 6 bundles openssl 1.0.2.h, where RHEL/CentOS have a much older version. That hasn't been an issue in Fedora; For CentOS, there is a build for Node.js 4 in cbs, including a patch to unbundle openssl and to make it work with the way older lib.
Unless we have a comparable patch (if possible) for Node version 6, maybe we should stick with version 4?
Matthias
On 08/22/2016 11:23 AM, Stephen Gallagher wrote:
On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
- We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly
requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana?
- Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
OK, I spent far too much of today attempting to solve this problem. I got fairly far into it, but at this point I have run out of time to work on it for the near future.
What I have been trying to do:
I decided that the most expedient approach for EPEL 7 right now would be to attempt to build OpenSSL statically into Node.js. We cannot do that with the copy that upstream carries due to certain patents, so I decided to see if I could script up something that would pull the source of the OpenSSL package from Fedora Rawhide, drop it into the Node.js source tree and allow us to build it.
This sounds simple in theory, but it turns out that it's going to require a fair bit of mucking about with the gyp build that Node.js uses. I've made some headway on it, but I am running out of steam. I just don't have anywhere near the level of knowledge of OpenSSL to make this work.
I've pushed my WIP to https://github.com/sgallagher/nodejs-fedora (the latest commit in the master branch is the interesting piece). I'd really appreciate it if someone else could take a look and try to help get it building under EPEL 7.
On 09/08/2016 11:27 AM, Stephen Gallagher wrote:
On 08/22/2016 11:23 AM, Stephen Gallagher wrote:
On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
- We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly
requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana?
- Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
OK, I spent far too much of today attempting to solve this problem. I got fairly far into it, but at this point I have run out of time to work on it for the near future.
What I have been trying to do:
I decided that the most expedient approach for EPEL 7 right now would be to attempt to build OpenSSL statically into Node.js. We cannot do that with the copy that upstream carries due to certain patents, so I decided to see if I could script up something that would pull the source of the OpenSSL package from Fedora Rawhide, drop it into the Node.js source tree and allow us to build it.
This sounds simple in theory, but it turns out that it's going to require a fair bit of mucking about with the gyp build that Node.js uses. I've made some headway on it, but I am running out of steam. I just don't have anywhere near the level of knowledge of OpenSSL to make this work.
I've pushed my WIP to https://github.com/sgallagher/nodejs-fedora (the latest commit in the master branch is the interesting piece). I'd really appreciate it if someone else could take a look and try to help get it building under EPEL 7.
RDO in CentOS 7 (and soon the OpsTools SIG) are using this nodejs patch which allows it to work with openssl 1.0.1: https://github.com/rdo-common/nodejs/blob/rdo-common/0002-Use-openssl-1.0.1....
This patch has been approved by the crypto team.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o...
On Thu, Sep 08, 2016 at 01:27:54PM -0400, Stephen Gallagher wrote:
- Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL.
Have you got details on what exactly is required from 1.0.2? Is it ALPN support?
I strongly suspect it will be possible (with sufficient effort) to patch node to build against older OpenSSL, albeit at the cost of losing some features.
There is a trade-off here between disabling 1.0.2 features & waiting for RHEL OpenSSL to catch up, versus having to maintain & patch a copy of OpenSSL 1.0.2 in addition to the RHEL OpenSSL. i.e. someone is ready to deal with patching all future Critical security issues in a bundled OpenSSL.
Regards, Joe
On 09/08/2016 01:27 PM, Stephen Gallagher wrote:
On 08/22/2016 11:23 AM, Stephen Gallagher wrote:
OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
- We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly
requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana?
- Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
Thanks to a lot of help from Haikel Guemar, I now have working builds of Node.js 6.5.0 against EPEL 7. His team was able to write adapt a patch that Solaris folks wrote to work against OpenSSL 1.0.1. I have put them up in a COPR[1] and also am running a build in the official EPEL 7 branch which I will get into updates-testing ASAP.
This *is* a world-breaking change. There have been numerous backwards-incompatible changes since Node.js 0.10.x, so testing will be imperative.
Reminder: Node.js 0.10.x hits EOL on 2016-10-01, so there is no hanging on to the old version.
[1] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
On 08/11/2016 05:43 AM, Stephen Gallagher wrote:
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in EPEL is pretty outdated. The current v0.10 that we have will go EOL in October and npm (package manager) is already not maintained.
Currently, upstreams' plan is to have two versions of Long Term Support (LTS) at once, one in active development and one in maintenance mode. Currently active is v4, which is switching to maintenance in April and v6 which is switching to LTS in October. This is also reason why we would like to skip v4, although both will get security updates. Nodejs v6 also comes with newer npm and v8 (which might best be bundled, as it is in Fedora and Software Collections) (v8 might concern ruby and database maintainers, but old v8 package still remains in the repo).
There was also an idea to have both LTS versions in repo, but we're not quite sure, how we'd do it and if it's even a good idea.
Also, another thing is, if it is worth of updating every year to new LTS or update only after the current one goes EOL. According to guidelines, I'd say it's the latter, but it's not exactly how node development works and some feedback from users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6, v4: will update sooner, shorter support (2018-04-01) v6: longer support (2019-04-01), *might* break more things, won't be in stable sooner than mid-October if everything goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until mid-October. What Zuzana and I discussed on another list is that the Node.js v6 schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. However, v6 is already out and available. The major thing that changes at that point is just that from then on, they commit to adding no more major features (as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in updates-testing for at least a month prior to declaring it stable (with autokarma disabled) with wide announcements about the impending upgrade. This will be safe to do since Node.js 6.x has already reached a point where no backwards-incompatible changes are allowed in, so we can start the migration process early.
How does EPEL deal with the fact that nodejs won't work with openssl 1.0.1? For CentOS we have a patch that allows nodejs 4.x to build with openssl 1.0.1 in EL7. Are you using a similar patch? Do you know if the same patch will work with nodejs 6.x?
Also need feedback from users.
I hope I didn't forget anything important.
Regards
Zuzka Node.js SIG
epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o...
On Thu, Aug 25, 2016 at 10:48 AM, Rich Megginson rmeggins@redhat.com wrote:
How does EPEL deal with the fact that nodejs won't work with openssl 1.0.1? For CentOS we have a patch that allows nodejs 4.x to build with openssl 1.0.1 in EL7. Are you using a similar patch? Do you know if the same patch will work with nodejs 6.x?
Well, OpenSSL 1.1.0 just arrived[1]. It should be safe to use that with nodejs6, nginx, and everything else needing new APIs without conflicting with the system openssl libs. This would essentially provide the same solution we've done in the past with openssl101e for EL5.
[1]: https://www.openssl.org/news/openssl-1.1.0-notes.html
On 08/25/2016 03:32 PM, Neal Gompa wrote:
On Thu, Aug 25, 2016 at 10:48 AM, Rich Megginson rmeggins@redhat.com wrote:
How does EPEL deal with the fact that nodejs won't work with openssl 1.0.1? For CentOS we have a patch that allows nodejs 4.x to build with openssl 1.0.1 in EL7. Are you using a similar patch? Do you know if the same patch will work with nodejs 6.x?
Well, OpenSSL 1.1.0 just arrived[1]. It should be safe to use that with nodejs6, nginx, and everything else needing new APIs without conflicting with the system openssl libs.
That means nodejs, etc. do not use the system openssl libs? How is that managed? What is the procedure for CVEs, security errata, etc.?
This would essentially provide the same solution we've done in the past with openssl101e for EL5.
On 08/25/2016 03:32 PM, Neal Gompa wrote:
That means nodejs, etc. do not use the system openssl libs? How is that managed? What is the procedure for CVEs, security errata, etc.?
Up until today, Node.js in EPEL 6 and 7 was using the very old 0.10.x series which was compatible with our system OpenSSL. However, Node.js 4.x and later requires at least 1.0.2... or at least I thought it did until I saw the RDO patch in this thread.
I'm going to explore that option today; it may indeed be the easiest answer.
To answer your question: current versions of Node.js use the system libs, so they're covered. That being said, Node.js upstream follows the CVE announcements of OpenSSL closely and regularly releases new versions with those fixes applied. (Not that it matters in our case).
epel-devel@lists.fedoraproject.org
-
Joe Orton -
Matthias Runge -
Neal Gompa -
Peter Robinson -
Rich Megginson -
Stephen Gallagher -
Stephen John Smoogen -
Zuzana Svetlikova