Hello
again!
obviously,
since there is no openresty-openssl custom src for 1.0.2i,
self-compiling is not an option. due to the "custom" src
requirement, one cannot compile openresty together with
openssl's own src. this last fact must have escaped the
attention of some.
https://github.com/openresty/openresty-packaging/blob/master/rpm/SPECS/openresty-openssl.spec
This is the spec file that is used to build the
openssl package that comes with the RHEL/CentOS/Fedora
OpenResty Package. There seems to be one patch applied, and
this patch file seems to apply correctly to the latest 1.0.2i
openssl src, so it's likely that you can build it yourself if
needed. You will still need to restart openresty after
rebuilding/installing the newer openssl shared library if you
take this route.
i
am a stolid practitioner of "common sense" and fully
appreciate comments in this vein. i am far less likely
to be impressed with snide and/or uniformed comments.
No one that has replied here is being snide with you, or seems
to be uninformed. I personally agree with the timing comments
and severity assessment done by Robert Paprocki, there seems
to be very little of immediate interest in the latest openssl
patch and if you disagree you can download the latest src and
build using the open-source package spec I linked for you
above. Dist friendly packaged OpenResty is still very much an
immature thing, this project has existed for years with zero
official package support for any major distributions. I
personally wanted to migrate my build/maint scripts to use the
recently released packages if any become available for debian,
but the dependence on a pre-packaged openssl binary is the
largest thing holding me back from adopting the package dist
and switching away from src building.
As for package maintenance timetables, the main owner of
this package lives in or near china and does not usually start
responding to these lists until later in the day US Time. If
you are using the openresty binary packages you will want to
build in at the very least an expected 24h wait period before
things like upstream changes from openssl are
included/updated/notified. The openssl project like to hold
back their final patches until they very last available second
for general public consumption mainly to prevent people
reverse-engineering their high-classified security patches
from becoming active 0-days. The only people who get advanced
notice of these critical fixes and the relevant source-code
patches are the most trusted general package dist maintainers,
and the largest consumers of their technology (companies like
google, amazon, etc.), of which openresty's package does not
qualify.
although self-reporting/-assessing CVE
vulnerability ratings involves subjectivity, the
assessment is meant to include analyzing the degree of
sophistication required, the likelihood that that
sophistication may be applied, whether an exploit
requires internal access to the system or may be
implemented externally, whether the result is merely
noisome or an instrumental compromise, the projection of
the number of systems that might be affected, et cetera.
thus low/medium/high has different meanings to different
admins. also, a 'low' quickly becomes a personal 'high'
when you are the one affected.
While I
don't want to discount your assessment of the severity of
the recent openssl CVE disclosures, they seem very mild and
should not concern the vast vast majority of system hosts
unless you are seeing symptoms of an attack related to
today's disclosures. Though it is possible as outlined
above, there is no immediate need to patch/restart out of
date systems out of band of normal scheduled maintenance.
I
assume an updated build of openresty-openssl will be coming out "soon" ™, but no one can
really put a date on it. If you want to have more control
over when updates like this take place, you can build
directly from source and eliminate
third party delays in your maintenance schedule.
-Matt
.
