Files
mars-nwe/third_party/README.md
2026-06-02 12:01:35 +02:00

119 lines
4.7 KiB
Markdown

# 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:
```sh
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: 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:
```text
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:
```text
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:
```text
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.