Cannot compile with OpenSSL 1.1.0l

[dima91]

Cannot compile with OpenSSL 1.1.0l

[neverpanic]

NID_ED448 and NID_ED25519 were introduced by openssl/openssl@9691a74. It seems that was only available with OpenSSL 1.1.1, unfortunately.

I'm not sure how hard it would be to compile MoCOCrW against OpenSSL 1.1.0 while disabling the newer features. Is using OpenSSL 1.1.1 an option for you?

As for the CMake warning, we should probably add a project() statement.

[dima91]

It could be a feasible option, we could try a test.

We need your library because we are implementing a standard for secured communications in the field of vehicular communications (this link contains a piece of the whole infrastructure: see paragraph 3.5) and we already developed signature and verification using this OpenSSL version.

My concern is to cancel the work done so far, but today we can perform some tests.

[dima91]

I've installed [email protected], but this error has been thrown:

root@iotg5-sec-a:~# cmake --build build
Scanning dependencies of target mococrw
[  4%] Building CXX object src/CMakeFiles/mococrw.dir/asn1time.cpp.o
[  8%] Building CXX object src/CMakeFiles/mococrw.dir/asymmetric_crypto_ctx.cpp.o
[ 13%] Building CXX object src/CMakeFiles/mococrw.dir/basic_constraints.cpp.o
[ 17%] Building CXX object src/CMakeFiles/mococrw.dir/bio.cpp.o
[ 21%] Building CXX object src/CMakeFiles/mococrw.dir/ca.cpp.o
[ 26%] Building CXX object src/CMakeFiles/mococrw.dir/crl.cpp.o
[ 30%] Building CXX object src/CMakeFiles/mococrw.dir/csr.cpp.o
[ 34%] Building CXX object src/CMakeFiles/mococrw.dir/distinguished_name.cpp.o
[ 39%] Building CXX object src/CMakeFiles/mococrw.dir/ecies.cpp.o
[ 43%] Building CXX object src/CMakeFiles/mococrw.dir/hash.cpp.o
[ 47%] Building CXX object src/CMakeFiles/mococrw.dir/kdf.cpp.o
[ 52%] Building CXX object src/CMakeFiles/mococrw.dir/key.cpp.o
[ 56%] Building CXX object src/CMakeFiles/mococrw.dir/key_usage.cpp.o
[ 60%] Building CXX object src/CMakeFiles/mococrw.dir/mac.cpp.o
[ 65%] Building CXX object src/CMakeFiles/mococrw.dir/openssl_lib.cpp.o
[ 69%] Building CXX object src/CMakeFiles/mococrw.dir/openssl_wrap.cpp.o
In file included from /root/MoCOCrW/src/openssl_wrap.cpp:32:0:
/root/MoCOCrW/src/cppc/checkcall.hpp:216:32: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
 #pragma GCC diagnostic ignored "-Wnoexcept-type"
                                ^~~~~~~~~~~~~~~~~
[ 73%] Building CXX object src/CMakeFiles/mococrw.dir/subject_key_identifier.cpp.o
[ 78%] Building CXX object src/CMakeFiles/mococrw.dir/symmetric_crypto.cpp.o
/root/MoCOCrW/src/symmetric_crypto.cpp: In destructor 'mococrw::AESCipherBuilder::~AESCipherBuilder()':
/root/MoCOCrW/src/symmetric_crypto.cpp:379:9: error: '::explicit_bzero' has not been declared
         ::explicit_bzero(reinterpret_cast<void *>(_secretKey.data()),
         ^~
src/CMakeFiles/mococrw.dir/build.make:300: recipe for target 'src/CMakeFiles/mococrw.dir/symmetric_crypto.cpp.o' failed
make[2]: *** [src/CMakeFiles/mococrw.dir/symmetric_crypto.cpp.o] Error 1
CMakeFiles/Makefile2:149: recipe for target 'src/CMakeFiles/mococrw.dir/all' failed
make[1]: *** [src/CMakeFiles/mococrw.dir/all] Error 2
Makefile:146: recipe for target 'all' failed
make: *** [all] Error 2

[neverpanic]

We need your library because we are implementing a standard for secured communications in the field of vehicular communications (this link contains a piece of the whole infrastructure: see paragraph 3.5) and we already developed signature and verification using this OpenSSL version.

I couldn't find a section 3.5 in this document. Can you elaborate?
Also, our library provides wrappers for signature and signature verification, maybe those would be an option for you?

In file included from /root/MoCOCrW/src/openssl_wrap.cpp:32:0:
/root/MoCOCrW/src/cppc/checkcall.hpp:216:32: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
 #pragma GCC diagnostic ignored "-Wnoexcept-type"
                                ^~~~~~~~~~~~~~~~~

Which compiler and compiler version are you using?

/root/MoCOCrW/src/symmetric_crypto.cpp: In destructor 'mococrw::AESCipherBuilder::~AESCipherBuilder()':
/root/MoCOCrW/src/symmetric_crypto.cpp:379:9: error: '::explicit_bzero' has not been declared
         ::explicit_bzero(reinterpret_cast<void *>(_secretKey.data()),
         ^~

We use explicit_bzero to securely delete data, but explicit_bzero is only available in glibc (which I'm guessing you're not using?). We have meanwhile introduced an alternative in mococrw::utility::vectorCleanse(), which uses OPENSSL_cleanse for the same purpose. You can probably get this to build by replacing the call to explicit_bzero with vectorCleanse. If that works for you, it would be appreciated if you submitted a pull request with this change.

[dima91]

I couldn't find a section 3.5 in this document. Can you elaborate?
Also, our library provides wrappers for signature and signature verification, maybe those would be an option for you?

I'm sorry, the section is at paragraph 5.3: there you can see a simple scenario and signed messages should be exchanged between vehicles and encrypted messages should be used to communicate with the PKI.
We can use your library also for signature and signature verification, it is a reasonable option!

Regarding the problem, those are the compilers we are using:

dpkg --list | grep compiler
ii  g++                                    4:6.3.0-4                         amd64        GNU C++ compiler
ii  g++-6                                  6.3.0-18+deb9u1                   amd64        GNU C++ compiler
ii  gcc                                    4:6.3.0-4                         amd64        GNU C compiler
ii  gcc-6                                  6.3.0-18+deb9u1                   amd64        GNU C compiler
ii  libllvm3.8:amd64                       1:3.8.1-24                        amd64        Modular compiler and toolchain technologies, runtime library
ii  libllvm3.9:amd64                       1:3.9.1-9                         amd64        Modular compiler and toolchain technologies, runtime library

Using vectorCleanse instead of explicit_bzero, for me compile perfectly!
I also tried to perform tests and it passes EciesSchemesTest so it is a good news! (but it fails on BioTests).

Can I submit a pull request? Should I change something else other than those two lines?

[neverpanic]

I've opened a pull request for this now in #76.

[dima91]

Ok, thank you very much!

[neverpanic]

Regarding the problem, those are the compilers we are using:

dpkg --list | grep compiler
ii  g++                                    4:6.3.0-4                         amd64        GNU C++ compiler
ii  g++-6                                  6.3.0-18+deb9u1                   amd64        GNU C++ compiler
ii  gcc                                    4:6.3.0-4                         amd64        GNU C compiler
ii  gcc-6                                  6.3.0-18+deb9u1                   amd64        GNU C compiler
ii  libllvm3.8:amd64                       1:3.8.1-24                        amd64        Modular compiler and toolchain technologies, runtime library
ii  libllvm3.9:amd64                       1:3.9.1-9                         amd64        Modular compiler and toolchain technologies, runtime library

It seems GCC 6 just didn't yet have the warning we're disabling with -Wnoexcept-type, so you can just ignore this warning.

I also tried to perform tests and it passes EciesSchemesTest so it is a good news! (but it fails on BioTests).

Can you provide the output of the failing test?

[dima91]

This is the output:

root@d4440e68b019:~/sharedv/build# ctest . --output-on-failure
Test project /root/sharedv/build
      Start  1: OpenSSLTest
 1/20 Test  #1: OpenSSLTest ......................   Passed    0.02 sec
      Start  2: Asn1TimeTests
 2/20 Test  #2: Asn1TimeTests ....................   Passed    0.01 sec
      Start  3: HashTests
 3/20 Test  #3: HashTests ........................   Passed    0.01 sec
      Start  4: UtilTests
 4/20 Test  #4: UtilTests ........................   Passed    0.00 sec
      Start  5: KeyTest
 5/20 Test  #5: KeyTest ..........................   Passed    4.96 sec
      Start  6: CsrTests
 6/20 Test  #6: CsrTests .........................   Passed    0.08 sec
      Start  7: BioTests
 7/20 Test  #7: BioTests .........................***Failed    0.00 sec
Running main() from gmock_main.cc
[==========] Running 7 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 7 tests from BioTest
[ RUN      ] BioTest.testReadingAndWritingToBio
[       OK ] BioTest.testReadingAndWritingToBio (0 ms)
[ RUN      ] BioTest.testReadingAndWritingToBioInBinary
[       OK ] BioTest.testReadingAndWritingToBioInBinary (0 ms)
[ RUN      ] BioTest.testOpenFileBioForReading
[       OK ] BioTest.testOpenFileBioForReading (0 ms)
[ RUN      ] BioTest.testOpenFileBioForWriting
[       OK ] BioTest.testOpenFileBioForWriting (1 ms)
[ RUN      ] BioTest.testOpenNonexistingFileForReading
[       OK ] BioTest.testOpenNonexistingFileForReading (0 ms)
[ RUN      ] BioTest.testOpenAccessDeniedWriting
/root/sharedv/MoCOCrW/tests/unit/test_bio.cpp:103: Failure
Expected: { FileBio testFileBio("/root/iAmNotAllowedHere.file", FileBio::FileMode::WRITE, FileBio::FileType::TEXT); } throws an exception of type OpenSSLException.
  Actual: it throws nothing.
[  FAILED  ] BioTest.testOpenAccessDeniedWriting (0 ms)
[ RUN      ] BioTest.testFileBioReadingWorks
[       OK ] BioTest.testFileBioReadingWorks (0 ms)
[----------] 7 tests from BioTest (1 ms total)

[----------] Global test environment tear-down
[==========] 7 tests from 1 test case ran. (1 ms total)
[  PASSED  ] 6 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BioTest.testOpenAccessDeniedWriting

 1 FAILED TEST

      Start  8: DistinguishedNameTests
 8/20 Test  #8: DistinguishedNameTests ...........   Passed    0.00 sec
      Start  9: X509Tests
 9/20 Test  #9: X509Tests ........................   Passed    0.09 sec
      Start 10: CRLTests
10/20 Test #10: CRLTests .........................   Passed    0.01 sec
      Start 11: VerificationTests
11/20 Test #11: VerificationTests ................   Passed    0.27 sec
      Start 12: CATests
12/20 Test #12: CATests ..........................   Passed    2.59 sec
      Start 13: SignatureTests
13/20 Test #13: SignatureTests ...................   Passed    0.09 sec
      Start 14: AsymEncryptionTests
14/20 Test #14: AsymEncryptionTests ..............   Passed    0.02 sec
      Start 15: RSAPaddingModeTests
15/20 Test #15: RSAPaddingModeTests ..............   Passed    0.08 sec
      Start 16: SymmetricCipherTest
16/20 Test #16: SymmetricCipherTest ..............   Passed    0.84 sec
      Start 17: SymmetricCipherMemoryModelTest
17/20 Test #17: SymmetricCipherMemoryModelTest ...   Passed    0.00 sec
      Start 18: KdfSchemesTest
18/20 Test #18: KdfSchemesTest ...................   Passed    0.01 sec
      Start 19: MacSchemesTest
19/20 Test #19: MacSchemesTest ...................   Passed    0.00 sec
      Start 20: EciesSchemesTest
20/20 Test #20: EciesSchemesTest .................   Passed    0.02 sec

95% tests passed, 1 tests failed out of 20

Total Test time (real) =   9.13 sec

The following tests FAILED:
	  7 - BioTests (Failed)
Errors while running CTest

[neverpanic]

Are you running the build and tests with root privileges? If so, please don't do that.

[dima91]

It is a problem since I'm using a Docker image. By running test as non-root user there aren't problems, but in "production" can this problem cause failures?

[garw]

Hi,
the public travis-ci of this project also uses a Docker image to build it. However, we configured the docker container to use a non-root user to run build and test: See https://github.com/fmonteiro93/MoCOCrW-build-env

In general, one should avoid using root whever possible, so this design follows the principle of least privilege.

I fear that I don't understand about which issues in "production" you are concerned.

[dima91]

Ok, I understood the problem.
With in production I mean the moments when we perform compliance tests with other vendors.

[neverpanic]

The BioTest testcase that fails failed because it assumes that it will not have write access to /root. This is an assumption made by the test, not by the library itself. Running the library in production under the root user, while still strongly discouraged, should work without issues.

[dima91]

Ok, perfectly!
Thank you very much for your support! =)