Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cannot compile with OpenSSL 1.1.0l #75

Closed
dima91 opened this issue Jun 22, 2020 · 15 comments
Closed

Cannot compile with OpenSSL 1.1.0l #75

dima91 opened this issue Jun 22, 2020 · 15 comments

Comments

@dima91
Copy link

dima91 commented Jun 22, 2020

Hello!
I'm trying to compile this library in a docker image with OpenSSL at version 1.1.0l, but when I start to compile the process fails immediately:

root@4cba3a1fe286:~# cmake -Bbuild -SMoCOCrW -DBUILD_TESTING=Off                       
CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.1.0l")  
-- Using OpenSSL 1.1.0l
-- Found Boost: /usr/include (found version "1.62.0")  
-- Configuring done
-- Generating done
-- Build files have been written to: /root/build
root@4cba3a1fe286:~# cmake --build build
Scanning dependencies of target mococrw
[  4%] Building CXX object src/CMakeFiles/mococrw.dir/asn1time.cpp.o
In file included from /root/MoCOCrW/src/mococrw/asn1time.h:21:0,
                 from /root/MoCOCrW/src/asn1time.cpp:19:
/root/MoCOCrW/src/mococrw/openssl_wrap.h:1349:13: error: 'NID_ED448' was not declared in this scope
     Ed448 = NID_ED448,
             ^~~~~~~~~
/root/MoCOCrW/src/mococrw/openssl_wrap.h:1350:15: error: 'NID_ED25519' was not declared in this scope
     Ed25519 = NID_ED25519
               ^~~~~~~~~~~
src/CMakeFiles/mococrw.dir/build.make:79: recipe for target 'src/CMakeFiles/mococrw.dir/asn1time.cpp.o' failed
make[2]: *** [src/CMakeFiles/mococrw.dir/asn1time.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

The branch I'm trying to compile is openssl1.1.

Can you help me?
@neverpanic
Copy link
Contributor

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
Copy link
Author

dima91 commented Jun 22, 2020

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
Copy link
Author

dima91 commented Jun 22, 2020

I've installed openssl@1.1.1, 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
Copy link
Contributor

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
Copy link
Author

dima91 commented Jun 22, 2020

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 pushed a commit to neverpanic/MoCOCrW that referenced this issue Jun 22, 2020
symmetric: Avoid non-standard explicit_bzero(3)
84c39a5 
explicit_bzero(3) is a glibc extension and may not be available, for
example on systems using musl. We have a good alternative in
util::vectorCleanse(), which uses OPENSSL_cleanse(3), so use that
instead.

See: bmwcarit#75
@neverpanic neverpanic mentioned this issue Jun 22, 2020
Merged
@neverpanic
Copy link
Contributor

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

@dima91
Copy link
Author

dima91 commented Jun 22, 2020

Ok, thank you very much!

@neverpanic
Copy link
Contributor

neverpanic commented Jun 22, 2020 •
edited
Loading

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?

neverpanic pushed a commit that referenced this issue Jun 22, 2020
@neverpanic
symmetric: Avoid non-standard explicit_bzero(3)
999c791 
explicit_bzero(3) is a glibc extension and may not be available, for
example on systems using musl. We have a good alternative in
util::vectorCleanse(), which uses OPENSSL_cleanse(3), so use that
instead.

See: #75
@dima91
Copy link
Author

dima91 commented Jun 23, 2020

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
Copy link
Contributor

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

@dima91
Copy link
Author

dima91 commented Jun 23, 2020

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
Copy link
Member

garw commented Jun 23, 2020

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
Copy link
Author

dima91 commented Jun 23, 2020

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

@neverpanic
Copy link
Contributor

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
Copy link
Author

dima91 commented Jun 23, 2020

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

@dima91 dima91 closed this as completed Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@neverpanic @dima91 @garw