# 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.