I took a quick glance at the build output, and I don't think openssl
is getting linked statically into libhadooppipes.a.

I see the following lines:

Linking CXX static library libhadooppipes.a
/usr/bin/cmake -P CMakeFiles/hadooppipes.dir/cmake_clean_target.cmake
/usr/bin/cmake -E cmake_link_script
CMakeFiles/hadooppipes.dir/link.txt --verbose=1
/usr/bin/ar cr libhadooppipes.a
/usr/bin/ranlib libhadooppipes.a

later on there are lines like this:

/usr/bin/c++    -g -Wall -O2 -D_REENTRANT -D_GNU_SOURCE
CMakeFiles/pipes-sort.dir/main/native/examples/impl/sort.cc.o  -o
examples/pipes-sort -rdynamic libhadooppipes.a libhadooputils.a -lssl
-lcrypto -lpthread

So when using libhadooppipes.a, you must supply your own copy of
libssl.so.  If you supply a vulnerable copy, you will be vulnerable.
If you supply a non-vulnerable copy, you won't be.  So I don't think
there is an impact on our build (unless I missed something here).

Just to make sure, it would be good if someone who uses
libhadooppipes.a to look at one of the versions in our release tarball
and verify that it works with the fixed openssl.


On Fri, Apr 11, 2014 at 2:27 AM, Vinayakumar B <[EMAIL PROTECTED]> wrote:

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB