Test "check-security-hardening" FAILED [SOLVED]

[mmoussouni]

Hello,
While executing tests right after a fresh v1.0.12 install on CentOS7, i get a failed check. Even more worrying that its named “check-security-hardening” :

===== BEGIN: /usr/src/zcash/qa/zcash/check-security-hardening.sh
[...]
Checking binary security of [zcashd zcash-cli zcash-tx]...
zcash-cli: failed NX RELRO
zcash-tx: failed NX RELRO
make: *** [check-security] Erreur 1
[...]
===== FAILED: /usr/src/zcash/qa/zcash/check-security-hardening.sh

I’ll try to have a look at source code but i’m not an expert at all so i still need help at the moment.

Thanks for helping!

PS: I saw similar but unanswered topic from a year ago : Check-security-hardening failed

[daira]

This is probably Building on debian with GCC 6 (and/or updated binutils, maybe?) fails during check-security-hardening.sh · Issue #2212 · zcash/zcash · GitHub . Which GCC and binutils versions did you build with?

[mmoussouni]

Versions:

• GCC 4.9.2 20150212 (Red Hat 4.9.2-6) (gcc -v)
• GNU ld version 2.24 (ld -v)
• GNU assembleur 2.24 […] BFD version 2.24 (as -v)

And this is an enlighted version of yum list installed (i tried to remove everything i know was out of topic but let in-scl unknown packages). And yes i use autotools-latest scl with devtoolset-3 to avoid out of date centOS packages.

scl enable devtoolset-3 ‘scl enable autotools-latest bash’

autoconf.noarch                         2.69-11.el7              @base
automake.noarch                         1.13.4-3.el7             @base

autotools-latest.x86_64                 1-14.el7.centos          @praiskup-autotools-epel-7-x86_64
autotools-latest-autoconf.noarch        2.69-4.el7.centos        @praiskup-autotools-epel-7-x86_64
autotools-latest-automake.noarch        1.15-4.el7.centos        @praiskup-autotools-epel-7-x86_64
autotools-latest-libtool.x86_64         2.4.2-16.el7.centos      @praiskup-autotools-epel-7-x86_64
autotools-latest-m4.x86_64              1.4.17-4.el7.centos      @praiskup-autotools-epel-7-x86_64
autotools-latest-runtime.x86_64         1-14.el7.centos          @praiskup-autotools-epel-7-x86_64

devtoolset-3.x86_64                               3.1-12.el7                        @centos-sclo-rh
devtoolset-3-binutils.x86_64                      2.24-18.el7                       @centos-sclo-rh
devtoolset-3-elfutils.x86_64                      0.161-1.el7                       @centos-sclo-rh
devtoolset-3-elfutils-libelf.x86_64               0.161-1.el7                       @centos-sclo-rh
devtoolset-3-elfutils-libs.x86_64                 0.161-1.el7                       @centos-sclo-rh
devtoolset-3-gcc.x86_64                           4.9.2-6.el7                       @centos-sclo-rh
devtoolset-3-gcc-c++.x86_64                       4.9.2-6.el7                       @centos-sclo-rhh
devtoolset-3-gdb.x86_64                           7.8.2-38.el7                      @centos-sclo-rh
devtoolset-3-icu4j.noarch                         1:54.1.1-4.4.el7                  @centos-sclo-rh
devtoolset-3-ide.x86_64                           3.1-12.el7                        @centos-sclo-rhlo-rh
devtoolset-3-libstdc++-devel.x86_64               4.9.2-6.el7                       @centos-sclo-rh
devtoolset-3-runtime.x86_64                       3.1-12.el7                        @centos-sclo-rh
devtoolset-3-toolchain.x86_64                     3.1-12.el7                        @centos-sclo-rh
devtoolset-3-xmlrpc-client.noarch                 1:3.1.3-8.4.el7                   @centos-sclo-rh
devtoolset-3-xmlrpc-common.noarch                 1:3.1.3-8.4.el7                   @centos-sclo-rh
devtoolset-3-xmlrpc-server.noarch                 1:3.1.3-8.4.el7                   @centos-sclo-rh

As i need to go, i’ll have a look later this day on the issue you linked.
Thanks for the help!

[daira]

Those version numbers aren’t consistent with the current hypothesis about what causes #2212, so it could be an independent problem.

I have another theory: I notice you’re running in a French-language locale, and the script might be too dependent on matching English output from the commands it uses. Can you try running in an English locale to check this?

[Edit: this theory is supported by the fact that in the previous forum post, the script ran in an Italian-language locale.]

[mmoussouni]

Hello,

I confirm the “check-security-hardening” test suite is OK using en_US.utf8 and en_GB.utf8 locale. It could be a good thing to add in the wiki “User Guide” page to change locale for the testing part: i’ll try to commit a clean edit .

So now i’m just getting the bitcoin test suite error but as buildbot encouters the same error (test/rpc_wallet_tests.cpp(285): error: in “rpc_wallet_tests/rpc_wallet”: unexpected exception thrown by CallRPC(“getblock 0”)) i’m not worrying a lot about it.

Thanks for the tip, i didn’t think to this possibility!

[mmoussouni]

GitHub issue created to inform devs :

check-security-hardening.sh - False negative result depending on locale

PS: I can’t edit my own posts, have to make a new one each time…

[mtve]

@mmoussouni

unexpected exception thrown by CallRPC(“getblock 0”)

would you please try just of curiosity:

zcash-cli getblock {anything}

i suspect it’s broken regex of centos system gcc.

[mmoussouni]

@mtve

would you please try just of curiosity:

zcash-cli getblock {anything}

i suspect it’s broken regex of centos system gcc.

Here is the output (for info, i’m with en_GB.utf8 local but i guess it’s not coming from here this time) :

[root@cryptocurrency zcash]# src/zcash-cli getblock 1000 # In-range
error code: -1
error message:
regex_error
[root@cryptocurrency zcash]# src/zcash-cli getblock 100000 # Out of range
error code: -1
error message:
regex_error

[root@cryptocurrency zcash]# src/zcash-cli getblockchaininfo # Current downloaded blocks
{
  "chain": "main",
  "blocks": 1465,
[...]

[daira]

Please file a separate Github issue for the regex_error problem, thanks.