required boost-libs not in Debian stable

[edermi]

Hi, while trying to update the Orka image I found out that Debian Stable currently contains version 1.55 of all boost libs. When installing them, the build still fails:

root@a496596ca0c9 ..arroumi2010/target/Whitebox-crypto-AES (git)-[master] # make
HOME: /root
NTL_INCLUDE_PATH: /usr/include
NTL_LIB: /usr/lib/libntl.so
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   program_options
--   serialization
--   iostreams
--   random
-- Configuring done
-- Generating done
-- Build files have been written to: /root/Deadpool/wbs_aes_karroumi2010/target/Whitebox-crypto-AES
[  4%] Building CXX object CMakeFiles/main.dir/base.cpp.o
[  8%] Building CXX object CMakeFiles/main.dir/BGEAttack.cpp.o
[ 12%] Building CXX object CMakeFiles/main.dir/BGEAttack_test.cpp.o
[ 16%] Building CXX object CMakeFiles/main.dir/GenericAES.cpp.o
[ 20%] Building CXX object CMakeFiles/main.dir/LinearAffineEq.cpp.o
[ 25%] Building CXX object CMakeFiles/main.dir/LinearAffineEq_test.cpp.o
[ 29%] Building C object CMakeFiles/main.dir/md5.c.o
[ 33%] Building CXX object CMakeFiles/main.dir/MixingBijections.cpp.o
[ 37%] Building CXX object CMakeFiles/main.dir/NTLUtils.cpp.o
/root/Deadpool/wbs_aes_karroumi2010/target/Whitebox-crypto-AES/NTLUtils.cpp: In function 'int char2int(char)':
/root/Deadpool/wbs_aes_karroumi2010/target/Whitebox-crypto-AES/NTLUtils.cpp:255:8: error: 'invalid_argument' is not a member of 'std'
  throw std::invalid_argument("Invalid input string");
        ^
CMakeFiles/main.dir/build.make:238: recipe for target 'CMakeFiles/main.dir/NTLUtils.cpp.o' failed
make[2]: *** [CMakeFiles/main.dir/NTLUtils.cpp.o] Error 1
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/main.dir/all' failed
make[1]: *** [CMakeFiles/main.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

Installing the packages from sid in stable doesn't sound like a good idea, so I'd suggest to build a statically
linked binary if nothing speaks against that. In my opinion, this is the easiest way for users to get everything up and running.

[doegox]

The error is unrelated with Boost.
See ph4r05/Whitebox-crypto-AES#10 for a fix.
I've pushed a version built against Boost 1.55:
https://github.com/SideChannelMarvels/Deadpool/blob/master/wbs_aes_karroumi2010/target/main_boost1.55

Cheers

[doegox]

BTW generally speaking I prefer to avoid statically linked libs in targets because in that case libs will be traced as well or they have to be explicitly ignored by a specific address range filter

[edermi]

That's a good point I didn't think about. Does something speak against providing both, e.g. the dynamically linked one for the "straight forward textbook analysis" and the static linked version for people using different systems/compilers/versions of the libraries? Occasionally I need to run
older code that does not build with current compilers/libraries and is not maintained anymore. Fixing these problems is annoying and if @ph4r05 / we decide to stop maintaining / working on this whitebox, people deciding to work with it in five or ten years have at least a statically linked binary to work with.

[doegox]

Hmm, why not.

If I do as following:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 94864e5..29bc4c0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,7 +2,9 @@ cmake_minimum_required(VERSION 2.8)
 project(Whitebox_crypto_AES)

 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O2 -std=c++0x")
-
+SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
+SET(BUILD_SHARED_LIBRARIES OFF)
+SET(CMAKE_EXE_LINKER_FLAGS "-static")
 set(SOURCE_FILES
     base.h
     base.cpp
@@ -47,6 +49,13 @@ set(Boost_USE_STATIC_RUNTIME OFF)
 find_package(Boost REQUIRED COMPONENTS program_options serialization iostreams random)
 include_directories(${Boost_INCLUDE_DIRS})

+find_library(GMP_LIB gmp PATHS /usr/local /opt/local $ENV{HOME}/gmp $ENV{HOME}/gmp/lib /usr)
+if(NOT GMP_LIB)
+    message(FATAL_ERROR "gmp library not found.  Rerun cmake with -DCMAKE_PREFIX_PATH=\"<path to lib1>;<path to lib2>\"")
+endif()
+message("GMP_LIB: ${GMP_LIB}")
+include_directories(${GMP_INCLUDE_PATH})
+
 # Linking
-target_link_libraries(main ${NTL_LIB} ${Boost_LIBRARIES})
-target_link_libraries(testing ${NTL_LIB} ${Boost_LIBRARIES})
+target_link_libraries(main ${NTL_LIB} ${GMP_LIB} ${Boost_LIBRARIES})
+target_link_libraries(testing ${NTL_LIB} ${GMP_LIB} ${Boost_LIBRARIES})

Then I end up with a 2Mb binary with deps to the std libs:

$ ldd main
    linux-vdso.so.1 (0x00007fff668ff000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7ed7b6b000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7ed7866000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ed74c1000)
    /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055738419e000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7ed72ab000)

I tried to add -static-libgcc -static-libstdc++ but they're still dynamically loaded, an idea?
Or is it already good enough like that?

[edermi]

After setting set(Boost_USE_STATIC_RUNTIME ON) I'm ending up with a static binary apart from a dynamically linked libc, too. I guess we have to build NTL and other dependencies statically linked in order to get a completely standalone executable. In order to keep the binary small, we may consider using musl or ulibc if it's compatible and not too much work. For now, having everything statically linked except libc is fine, but I will look into this.