mars-nwe/third_party

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.