OpenSSL doesn't support using BIOs of the "fd" or "file" type when it is
built as a DLL and the executable didn't provide it with access to the
executable's CRT. Requiring all applications that wish to use security
to worry about this "applink.c" thing is too onerous a requirement.
* Check for the existence of "applink.c" in the OpenSSL include
directory, adding it to the security tests if it exists. This way,
all of OpenSSL can be used by the tests.
* Include it in the security core and built-in plugin tests. This way,
the test code can use the entirety of OpenSSL.
* In the authentication and access-control plugins, load X509 and
private keys from files by first reading them into a "mem" type BIO,
then reading them from that BIO.
* Take care not to call ddsrt_free on OpenSSL-allocated memory, either
by calling OPENSSL_free, or by allocating the memory using
ddsrt_malloc and letting OpenSSL fill that buffer.
Signed-off-by: Erik Boasson <eb@ilities.com>
Fix and simplify building docs and schemas
1. Do an in-source build of derived schemas instead of building into build and checking that the files match.
2. Fix paths of installed docs, which were failing on me
3. Consolidate docs into same cmakelists that generates schema files
4. Trang is usually available as an executable, so find it with find_program.
5. Add doc dependencies to package.xml
Signed-off-by: Dan Rose <dan@digilabs.io>
Running tests while writing failed assertions to a text file means the
little information there is that causes test failures becomes pretty
much inaccessible on Travis. Sending the output to stdout/stderr means
it can be trivially shown for failed tests using the --output-on-failure
option of ctest.
Signed-off-by: Erik Boasson <eb@ilities.com>
Installing Cyclone DDS for multiple architectures with the same
installation prefix gave problems because the CMake configuration files
ended up overwriting each other. This brings it in line with the
recommended locations. Thanks to @hansfn.
Signed-off-by: Erik Boasson <eb@ilities.com>
This allows you to express a dependency on it as `find_package(CycloneDDS REQUIRED COMPONENTS idlc)`
Also added a warning if CycloneDDS was built with IDLC but IDLC is not requested.
Signed-off-by: Dan Rose <dan@digilabs.io>
Builtin authentication plugin of DDS Security implementation was added.
This plugin is the first implementation and it also contains the functions that are used initially in the secure communication sequence.
The builtin authentication plugin implements authentication using a trusted Certificate Authority (CA). It performs mutual authentication between discovered participants using the RSA or ECDSA Digital Signature Algorithms and establishes a shared secret using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) Key Agreement Methods.
DDS Security core component is introduced with this commit. DDSI and other builtin plugins will also use the security core.
Like all builtin plugins, dds security authentication plugin is a shared library for providing dynamic library loading on runtime. So that, dds participants can use different plugin implementations with different configurations.
Authentication plugin uses ddsrt functions. ddsrt is not expected to be a shared library and statically adding ddsrt objects to authentication library produces linkage errors in windows. So, dynamically linking authentication plugin to ddc library is decided. Another decision should be taken for the platforms that are not supporting dynamic libraries later.
Signed-off-by: Kurtulus Oksuztepe <kurtulus.oksuztepe@adlinktech.com>
This is useful when building CycloneDDS on platforms that provide CMake
configuration for CUnit outside of Conan.
If no configuration is found in the system CMake registry the module
continues as before.
Co-authored-by: Steven! Ragnarök <steven@nuclearsandwich.com>
Signed-off-by: Scott K Logan <logans@cottsay.net>
CMAKE_PROJECT_NAME refers to the top-level project name, not the most recent project. So any CMake project that pulls this in as a dependency was in for a nasty surprise.
https://cmake.org/cmake/help/latest/variable/CMAKE_PROJECT_NAME.html
Signed-off-by: Dan Rose <dan@digilabs.io>
Setting BUILD_IDLC=OFF makes it possible to build Cyclone without
its (Java-based) IDL preprocessor. In that case there is no
IdlcGenerate.cmake, and therefore the generated CycloneDDSConfig.cmake
must not try to include it either.
Signed-off-by: Erik Boasson <eb@ilities.com>
* Move the project top-level CMakeLists.txt to the root of the project;
this allows building Cyclone as part of ROS2 without any special
tricks;
* Clean up the build options:
ENABLE_SSL: whether to check for and include OpenSSL support if a
library can be found (default = ON); this used to be
called DDSC_ENABLE_OPENSSL, the old name is deprecated
but still works
BUILD_DOCS: whether to build docs (default = OFF)
BUILD_TESTING: whether to build test (default = OFF)
* Collect all documentation into top-level "docs" directory;
* Move the examples to the top-level directory;
* Remove the unused and somewhat misleading pseudo-default
cyclonedds.xml;
* Remove unused cmake files
Signed-off-by: Erik Boasson <eb@ilities.com>
