Installation fails when running OS in FIPS-enabled mode due to use of MD5

[agelwarg]

Installing nokogiri (1.6.8) sh: line 1: 6048 Aborted (core dumped) /somepath/vendor/ruby-2.1.2/bin/ruby extconf.rb 2>&1

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

/somepath/vendor/ruby-2.1.2/bin/ruby extconf.rb

Using pkg-config version 1.1.7
checking if the C compiler accepts ... yes
Building nokogiri using packaged libraries.
Using mini_portile version 2.1.0
checking for gzdopen() in -lz... yes
checking for iconv... yes

---

IMPORTANT NOTICE:

Building Nokogiri with a packaged version of libxml2-2.9.4.

Team Nokogiri will keep on doing their best to provide security
updates in a timely manner, but if this is a concern for you and want
to use the system library instead; abort this installation process and
reinstall nokogiri as follows:

gem install nokogiri -- --use-system-libraries
    [--with-xml2-config=/path/to/xml2-config]
    [--with-xslt-config=/path/to/xslt-config]

If you are using Bundler, tell it to use the option:

bundle config build.nokogiri --use-system-libraries
bundle install

Note, however, that nokogiri is not fully compatible with arbitrary
versions of libxml2 provided by OS/package vendors.

---

Extracting libxml2-2.9.4.tar.gz into tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.9.4... OK
md5_dgst.c(78): OpenSSL internal error, assertion failed: Digest MD5 forbidden in FIPS mode!

extconf failed, exit code 134

Gem files will remain installed in /somepath/vendor/bundle/ruby/2.1.0/gems/nokogiri-1.6.8 for inspection.
Results logged to /somepath/vendor/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0-static/nokogiri-1.6.8/gem_make.out

An error occurred while installing nokogiri (1.6.8), and Bundler cannot continue.
Make sure that gem install nokogiri -v '1.6.8' succeeds before bundling.

[ghost]

I am also having a problem with this as MD5 is not a FIPS-compliant algorithm.

At this point, md5 is really not a good choice for hashing algorithm, so I'm surprised to see this added so recently. Additionally, it seems this project added the md5sums themselves rather than referencing any upstream hashes, so this doesn't even really provide chain of trust validation.

Can this piece be removed or updated to use a better hash algorithm or better yet, use the gpg signatures from the upstream project?

[larskanis]

@nvtsgit We don't use gpg signatures for tar file verification, because it would add gpg as an install dependency.

[agelwarg]

@larskanis Any idea when the next release is coming that will include this?

[flavorjones]

Will be in v1.7.1.

[agelwarg]

This issue still exists in v1.7.1, although seemingly at a later point:

sh: line 1: 11740 Aborted                 (core dumped) /somepath/vendor/ruby-2.1.2/bin/ruby extconf.rb 2>&1
ERROR:  Error installing nokogiri:
        ERROR: Failed to build gem native extension.

    /somepath/vendor/ruby-2.1.2/bin/ruby extconf.rb
checking if the C compiler accepts ... yes
Building nokogiri using packaged libraries.
Using mini_portile version 2.1.0
checking for gzdopen() in -lz... yes
checking for iconv... yes
************************************************************************
IMPORTANT NOTICE:

Building Nokogiri with a packaged version of libxml2-2.9.4
with the following patches applied:
        - 0001-Fix-comparison-with-root-node-in-xmlXPathCmpNodes.patch
        - 0002-Fix-XPointer-paths-beginning-with-range-to.patch
        - 0003-Disallow-namespace-nodes-in-XPointer-ranges.patch

Team Nokogiri will keep on doing their best to provide security
updates in a timely manner, but if this is a concern for you and want
to use the system library instead; abort this installation process and
reinstall nokogiri as follows:

    gem install nokogiri -- --use-system-libraries
        [--with-xml2-config=/path/to/xml2-config]
        [--with-xslt-config=/path/to/xslt-config]

If you are using Bundler, tell it to use the option:

    bundle config build.nokogiri --use-system-libraries
    bundle install

Note, however, that nokogiri is not fully compatible with arbitrary
versions of libxml2 provided by OS/package vendors.
************************************************************************
Extracting libxml2-2.9.4.tar.gz into tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.9.4... OK
Running git apply with /somepath/vendor/ruby-2.1.2/lib/ruby/gems/2.1.0/gems/nokogiri-1.7.1/patches/libxml2/0001-Fix-comparison-with-root-node-in-xmlXPathCmpNodes.patch... OK
Running git apply with /somepath/vendor/ruby-2.1.2/lib/ruby/gems/2.1.0/gems/nokogiri-1.7.1/patches/libxml2/0002-Fix-XPointer-paths-beginning-with-range-to.patch... OK
Running git apply with /somepath/vendor/ruby-2.1.2/lib/ruby/gems/2.1.0/gems/nokogiri-1.7.1/patches/libxml2/0003-Disallow-namespace-nodes-in-XPointer-ranges.patch... OK
md5_dgst.c(78): OpenSSL internal error, assertion failed: Digest MD5 forbidden in FIPS mode!

extconf failed, exit code 134

Gem files will remain installed in /somepath/vendor/ruby-2.1.2/lib/ruby/gems/2.1.0/gems/nokogiri-1.7.1 for inspection.
Results logged to /somepath/vendor/ruby-2.1.2/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0-static/nokogiri-1.7.1/gem_make.out```

[flavorjones]

If this is a problem for you, I strongly recommend compiling against your system libraries. The instructions can be found at:

http://www.nokogiri.org/tutorials/installing_nokogiri.html#using_your_system_libraries

[flavorjones]

You'll also note that I changed the milestone on this story to v1.8.0, reflecting the fact that v1.7.1 was a security update to v1.7.0 and did not contain any new features like this.

We're planning to use SHA-256 in v1.8.0. See commit 1805544 for details

[agelwarg]

Ah, gotcha -- I didn't realize your fix was moved to v1.8.0. On a side note, how do I build the gem off master now so that I can test this pre-release version and see if it addresses the problem for us?

[agelwarg]

I think I figured it out using rake gem:spec and rake gem. As such, it built nokogiri-1.7.0.1.20170404163350.gem. However, I still get the same error. I'll dig deeper to see if I can find the root cause.

[agelwarg]

I traced this further and found this to be a problem inside of mini_portile2. Specifically, it uses MD5 for storing a hash of the configuration options when compiling (libxml2 in this case) -- it uses this info to decide if configuration needs to be run or if it's already been run (with the given options). When I patch mini_portile2 to use a SHA256 (or some other algorithm for making this decision), it works just fine. So, although the original issue was inside the nokogiri build process, this now appears to be a mini_portile2 issue. For reference, you can look at the code here (http://www.rubydoc.info/gems/mini_portile2/2.1.0/MiniPortile#configure-instance_method) and here (http://www.rubydoc.info/gems/mini_portile2/2.1.0/MiniPortile#configured?-instance_method).

I have opened this issue: flavorjones/mini_portile#78

[flavorjones]

I'm going to reopen this so that I remember to bump the dependency on mini_portile2 (presuming I get to doing that) before I release 1.8.0.

[larskanis]

This issue is addressed in flavorjones/mini_portile#79 . mini_portile is currently set to ~>2.1.0 in nokogiri, so that mini_portile needs to be released first and and the version constraint set to ~>2.2.0. Alternatively it's maybe better to use ~>2.1, as this is preferred for semantic versioning.

[flavorjones]

Will be in 1.8.0, which I'm cutting tonight.