On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson <pbrobinson(a)gmail.com>
> It turns out there's an additional issue; it appears that
> 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
> supersede RHEL and take them out of support on any package linking
> it (which now includes parts of SSSD).
> I'm going to spend a little time today trying to figure out if I can fix
> OpenSSL 1.0.1 compatibility patch and push out an update that will work
> 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
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.