mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity

docs: document tinyldap cmake split and TLS policy

Browse Source
This commit is contained in:
Mario Fetka
2026-06-02 09:59:27 +00:00
parent 63f99b0430
commit 6b39290be3
2 changed files with 79 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
REDESIGN.md
View File

@@ -1235,6 +1235,23 @@ If any old FLAIM crypto/TLS-related option is required for building, it must be
reviewed separately and kept isolated from mars-nwe provider IPC and LDAP TLS
policy.
If the FLAIM source cannot be built cleanly without old OpenSSL-facing code, the
preferred fallback is still not to introduce a general OpenSSL/LibreSSL backend
matrix. A narrowly scoped CMake option may use wolfSSL's OpenSSL-compatibility
headers only inside `third_party/libflaim`, for example:
```text
FLAIM_USE_WOLFSSL_OPENSSL_COMPAT=ON/OFF/AUTO
```
That option would be an import/portability bridge for FLAIM only. It must not
change the mars-nwe TLS policy, expose OpenSSL-compatible types outside the
FLAIM/FTK build, or make LDAP/provider IPC use OpenSSL APIs. If possible, the
classic `FLAIM::ftk` and `FLAIM::flaim` targets should disable old TLS-facing
code entirely. If crypto primitives are required, prefer a small private shim in
the FLAIM build over leaking wolfSSL/OpenSSL-compat headers into `libdirectory`,
`nwbind`, `nwdirectory`, or future `nwnds` code.
FLAIM is C++ code. That is acceptable, but its C++ API must not leak into the
old mars-nwe C code. `nwbind`, future `nwnds`, `nwdirectory`, and `nwsetup`
should use a C ABI through `include/libdirectory.h` or an equivalent internal
@@ -1274,6 +1291,54 @@ mars-nwe-specific work:
- later `libdirectory` and libflaim-backed storage integration;
- directory schema, bootstrap, and setup integration through `nwsetup`.
The inspected `tinyldap.tar` snapshot is a small C project with one handwritten
Makefile. That Makefile builds several static archives and utilities, including
ASN.1 helpers, LDAP encode/decode helpers, LDIF parsing, auth helpers, a storage
archive, a tiny TLS archive, `tinyldap`, `tinyldap_standalone`, debug/test
programs, index tools, ACL tools, an LDAP client, and conversion utilities. It
also expects libowfat-style headers/libraries and, when not using the old dietlibc
path, links OpenSSL/crypt-style libraries for some helper code. The CMake
conversion should inventory those groups explicitly instead of copying the old
`all` target wholesale.
A reasonable first CMake split is:
```text
tinyldap::asn1 ASN.1 scan/format helpers
tinyldap::ldap LDAP PDU scan/format/search-filter helpers
tinyldap::ldif LDIF parsing and LDAP matching helpers
tinyldap::auth password/auth helpers, later routed through libdirectory
tinyldap::storage original mmap/flat-file storage, legacy/transition only
tinyldap::server original tinyldap server logic, adapted for nwdirectory
```
Optional/off-by-default targets can cover old tools such as `parse`, `addindex`,
`dumpidx`, `idx2ldif`, `dumpacls`, `ldapclient`, `ldapdelete`, `asn1dump`,
`mysql2ldif`, debug binaries, and tests. mars-nwe should not require these tools
for the normal `nwdirectory` build unless a migration/setup workflow explicitly
needs them.
The original tinyldap TLS code (`tinytls.h`, `tls_*.c`, `fmt_tls_*.c`, and
`init_tls_context.c`) should not become the long-term TLS stack for mars-nwe.
Keep it as reference material or disable it in the integrated build. The
project-facing `nwdirectory` service should use `nwtls` backed by wolfSSL for
LDAPS/StartTLS, while the standalone tinyldap build may temporarily keep legacy
TLS behavior only if it is isolated behind CMake options and does not leak into
mars-nwe's TLS policy.
The original storage path is also transitional. Files such as `mstorage.*`,
`mduptab.*`, `strstorage.*`, and the `data`/index workflow described by the
upstream README are useful for understanding tinyldap's original database model,
but the mars-nwe `nwdirectory` target should move toward:
```text
nwdirectory -> libdirectory -> libflaim
```
Do not make `nwbind` or future `nwnds` depend on tinyldap's flat-file storage or
on the LDAP protocol just because the LDAP service happens to be present. The
shared directory API remains the internal boundary.
The CMake conversion should therefore support both use cases:
```text

14
third_party/README.md vendored
View File

@@ -60,6 +60,12 @@ 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
@@ -102,3 +108,11 @@ The planned tinyldap fork is such a component. It should live as
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.