6.2 KiB
Third-party dependencies
This directory is for mostly external building blocks that are built or linked by mars-nwe but are not project-specific service forks. Code here should normally be accessed through a mars-nwe facade or subsystem instead of being included from endpoint/provider code directly.
yyjson
The salvage metadata backend uses the bundled yyjson submodule for JSON read/write support. The submodule is required and is linked statically into the mars-nwe server targets that use salvage metadata.
Setup:
git submodule update --init --recursive third_party/yyjson
CMake expects third_party/yyjson/CMakeLists.txt to exist. Reader and writer
support stay enabled; yyjson tests, fuzzer, misc tools, docs, install targets,
JSON5/non-standard support, utilities and incremental reader support are disabled
for the mars-nwe build.
Planned: libowfat
libowfat is the planned hard bundled dependency for the tinyldap-derived
mars-tinyldap / nwdirectory work. It should live under
third_party/libowfat, not at the repository root, and should be treated as a
fixed third-party building block in the same sense as yyjson is fixed for
salvage metadata.
The reviewed archive is libowfat-0.34.tar.xz. Its README describes libowfat
as general-purpose APIs extracted from Dan Bernstein-style software and
reimplemented under GNU GPL Version 2 with no later-version grant. Record that
GPL-2.0-only license and the exact source/version in
third_party/libowfat/README.mars-nwe.md when the dependency is imported.
The first mars-nwe integration should provide a real CMake target, for example:
OWFAT::owfat
Do not rely on libowfat's original Makefile as the long-term build path. The
CMake import should be usable by both the standalone tinyldap-derived build and
the mars-nwe superbuild. The direct dependency should remain scoped to the
mars-tinyldap/nwdirectory compatibility code and any small wrapper needed for
that integration; unrelated NCP endpoint/provider code should not start
including libowfat headers directly just because the library is bundled.
Relevant libowfat areas for tinyldap are expected to include byte, buffer,
fmt, scan, str, stralloc, uint, open, socket, and possibly io or
cdb, depending on how much of the original tinyldap code is kept.
Planned: wolfSSL
wolfSSL is the planned fixed TLS implementation for mars-nwe. It should be
added as third_party/wolfssl and configured by CMake for the server's supported
platforms and enabled TLS features.
mars-nwe code should not include wolfSSL headers directly from arbitrary
subsystems. TLS users should go through the future include/nwtls.h facade and
its wolfSSL backend, for example:
include/nwtls.h
src/nwtls.c
src/nwtls_wolfssl.c
Planned uses include LDAP/LDAPS/StartTLS in nwdirectory and any future
TCP-based internal provider IPC that requires mTLS.
Planned: libflaim
libflaim is the planned bundled persistent storage engine for the future
libdirectory store. It belongs under third_party/libflaim because it is a
storage engine dependency, not a mars-nwe service fork.
The import should be mars-nwe-maintained. The initial source may come from the
SourceForge FLAIM code base or from a distro-vetted source package such as the
openSUSE libflaim-4.9.1046 source package. The exact source, version, distro
patches, licenses, and local changes must be documented in
third_party/libflaim/README.mars-nwe.md.
The original FLAIM build system should be replaced with a real CMake build, not wrapped from the mars-nwe build. The uploaded r1112 trunk snapshot already has Autotools files, but those should be treated as source inventory and build-check reference material. The resulting tree should build both as a standalone library project and as a mars-nwe subdirectory, exposing normal CMake targets.
If old FLAIM/FTK code requires OpenSSL-facing build paths, prefer disabling those
paths for the initial classic FLAIM::flaim target. If a compatibility bridge is
unavoidable, it should be a private third_party/libflaim CMake option using
wolfSSL's OpenSSL-compatible headers, not a new public OpenSSL/LibreSSL TLS
backend for mars-nwe.
The first required targets are expected to be:
FLAIM::ftk
FLAIM::flaim
SQL FLAIM, XFLAIM, tools, tests, generated documentation, package metadata, Windows projects, NetWare NLM files, Java/C# bindings, and other legacy build outputs should remain optional/off by default until mars-nwe actually needs them.
FLAIM is C++ code. mars-nwe C components should not include FLAIM C++ headers
directly. Access should go through the future libdirectory C API.
Planned: zlog
zlog is the planned optional advanced logging backend. If added, it should live
under third_party/zlog and be used only through the mars-nwe nwlog facade:
include/nwlog.h
src/nwlog.c
src/nwlog_zlog.c
Endpoint and provider code must not call zlog APIs directly. This keeps secret redaction, request correlation fields, and fallback logging centralized.
Forked components are not third_party
Components that are forked and integrated as mars-nwe services should live at the
repository root, following the existing pattern used by admin, dosutils,
mail, and smart.
The planned tinyldap fork is such a component. It should live as
mars-tinyldap/ at the repository root. Its standalone identity remains
tinyldap, while the mars-nwe integration builds the project-facing
nwdirectory service. The fork should gain a real CMake build that works both
standalone under the tinyldap name and as a mars-nwe subdirectory, and it should
later use libdirectory/libflaim-backed storage instead of tinyldap's original
flat-file storage.
The inspected tinyldap snapshot has one handwritten Makefile that builds ASN.1,
LDAP, LDIF, auth, storage, tiny TLS, server, client, index, ACL, conversion, and
test utilities. The mars-nwe CMake conversion should split those groups into
explicit libraries/targets instead of preserving the old monolithic all target.
The original tiny TLS code should be disabled or isolated for the integrated
nwdirectory target; LDAP/LDAPS/StartTLS in mars-nwe should use nwtls backed
by wolfSSL.