On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> It turns out there's an additional issue; it appears that Node.js 6.11.2
> with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
> EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
> upgraded to OpenSSL 1.0.2).
> I'm trying to figure out what to do here. We can't just put back the
> http-parser in EPEL unfortunately because the RHEL folks unintentionally
> released a lower NVR for the official package. If we put ours back, it would
> supersede RHEL and take them out of support on any package linking against
> it (which now includes parts of SSSD).

> I'm going to spend a little time today trying to figure out if I can fix the
> OpenSSL 1.0.1 compatibility patch and push out an update that will work with
> the bundled http-parser for now.

Can you not just rebuild nodejs, which will rebuild the bundled
http-parser, against the new 1.0.2 build in 7.4?

The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.

I'm trying right now to figure out if I build it for 1.0.1 functionality if 1.0.2 is sufficiently backwards-compatible. Because my initial glance suggests that it might not be and so I would have to choose between whether it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks CentOS 7.3 users.

For the record, this is irrespective of the http-parser issue. That one at least is solved just by carrying the bundled copy for a short time. But I can't do the same with OpenSSL because the Node.js bundled copy of OpenSSL is known to have encumbered codecs and I see no value in duplicating the effort of stripping them out.