From 26ff93eae4159e3f574060e1b30eff2488cb1aac Mon Sep 17 00:00:00 2001 From: Mario Fetka Date: Tue, 2 Jun 2026 22:14:53 +0000 Subject: [PATCH] docs: document libowfat hard dependency policy --- AI.md | 27 ++++++++++++++++++- REDESIGN.md | 62 ++++++++++++++++++++++++++++++++++++++++--- TODO.md | 24 +++++++++++++++++ third_party/README.md | 31 ++++++++++++++++++++++ 4 files changed, 140 insertions(+), 4 deletions(-) diff --git a/AI.md b/AI.md index 03da527..defbfc5 100644 --- a/AI.md +++ b/AI.md @@ -1300,4 +1300,29 @@ Next patch number should be `0253`. `include//*.h`, then move smaller modules such as `nwdirectory` before splitting very large files such as `nwconn.c` and `nwbind.c`. -Next patch number should be `0262`. +## 2026-06-02 - Patch 0262 libowfat hard dependency policy + +- Reviewed the uploaded `libowfat-0.34.tar.xz` archive as the dependency used + by tinyldap-style code. Its README states that libowfat provides general + purpose APIs extracted from Dan Bernstein's software and reimplemented under + GNU GPL version 2 only, with no later-version grant. +- Treat libowfat as a planned hard third-party dependency for the + tinyldap-derived `mars-tinyldap`/`nwdirectory` work, similar to how yyjson is + a required bundled dependency for salvage metadata. +- The planned import path is `third_party/libowfat`. Do not keep it merely as a + reference archive and do not place it at the repository root. +- The pinned initial source should be libowfat 0.34 unless a later explicit + dependency bump patch chooses a different version. The import must carry a + mars-nwe note documenting source/version, GPL-2.0-only license, local CMake + changes, and how `mars-tinyldap`/`nwdirectory` links it. +- The first integration should expose a normal CMake target, for example + `OWFAT::owfat`, and should be usable from both standalone `mars-tinyldap` and + the mars-nwe superbuild. Do not wrap libowfat's original Makefile as the + long-term build path. +- Scope the direct libowfat dependency to the tinyldap-derived directory-service + build and any small compatibility facade needed for it. Do not start using + libowfat APIs throughout unrelated `nwconn`, `nwbind`, or endpoint/provider + code merely because the library is bundled. +- Keep GPLv3 code out of this dependency path. + +Next patch number should be `0263`. diff --git a/REDESIGN.md b/REDESIGN.md index c24bda0..ddcc082 100644 --- a/REDESIGN.md +++ b/REDESIGN.md @@ -1530,6 +1530,11 @@ third_party/wolfssl fixed TLS dependency used by mars-nwe TLS code configured through CMake for the server's supported platforms and features +third_party/libowfat + planned fixed hard dependency for the tinyldap-derived nwdirectory work + imported from libowfat 0.34 unless a later dependency bump says otherwise + GPL-2.0-only; exposed through a CMake target such as OWFAT::owfat + third_party/libflaim planned fixed directory storage engine used through libdirectory mars-nwe-maintained import/fork of the FLAIM source @@ -1546,6 +1551,55 @@ mars-tinyldap/ later wired to libdirectory/libflaim instead of tinyldap's original flat files ``` +### libowfat dependency rule + +`libowfat` should be a hard bundled dependency for the tinyldap-derived +`mars-tinyldap`/`nwdirectory` work, not merely a reference archive. It belongs +under `third_party/libowfat` and should be handled like a fixed third-party +building block, similar to yyjson for salvage metadata. + +The reviewed source is `libowfat-0.34.tar.xz`. Its README describes libowfat as +a library of general-purpose APIs extracted from Dan Bernstein's software, +reimplemented under GNU GPL Version 2 with no later-version grant. The initial +import should therefore document `libowfat 0.34` and `GPL-2.0-only` explicitly in +`third_party/libowfat/README.mars-nwe.md`. + +The CMake integration should not simply shell out to libowfat's original +Makefile. It should expose a normal target usable by both standalone +`mars-tinyldap` and the mars-nwe superbuild, for example: + +```text +standalone: + cmake -S third_party/libowfat -B build-libowfat + +inside mars-nwe: + add_subdirectory(third_party/libowfat) + target_link_libraries(nwdirectory PRIVATE OWFAT::owfat) +``` + +The expected target name is: + +```text +OWFAT::owfat +``` + +The tinyldap-derived code may depend on libowfat directly where that matches the +upstream programming model. Broader mars-nwe endpoint/provider code should not +start including libowfat headers directly just because it is present in the tree. +If common mars-nwe code needs similar helpers later, add an explicit mars-nwe +facade or small local helper rather than leaking the tinyldap compatibility +library through `nwconn`, `nwbind`, or future provider boundaries. + +Areas of libowfat likely relevant to tinyldap include `byte`, `buffer`, `fmt`, +`scan`, `str`, `stralloc`, `uint`, `open`, `socket`, and possibly `io` or `cdb`. +Keep the first import focused on the parts required to build the tinyldap-derived +LDAP service; optional tools/tests/manpage installation can remain disabled until +there is a concrete maintenance need. + +Do not introduce GPLv3 code into this dependency path. If a later libowfat bump +or replacement is considered, review the license and make that a separate +third-party update patch. + ### TLS dependency rule wolfSSL should be the fixed TLS implementation shipped with the tree, similar in @@ -1733,9 +1787,11 @@ 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. +path, links OpenSSL/crypt-style libraries for some helper code. For the +mars-nwe integration, that libowfat expectation is intentional: `libowfat` is a +hard bundled dependency under `third_party/libowfat`, exposed as `OWFAT::owfat`. +The CMake conversion should inventory those groups explicitly instead of copying +the old `all` target wholesale. A reasonable first CMake split is: diff --git a/TODO.md b/TODO.md index 4aed987..680b134 100644 --- a/TODO.md +++ b/TODO.md @@ -174,6 +174,30 @@ Current status: `case 0x17`; SDK group `0x2222/123` is top-level wire `case 0x7b`. +#### libowfat hard dependency for tinyldap/nwdirectory + +Current status: + +- Patch `0262` records libowfat as a planned hard third-party dependency for the + tinyldap-derived `mars-tinyldap` / `nwdirectory` work. +- The reviewed archive is `libowfat-0.34.tar.xz`; its README states that the + library is GPL Version 2 with no later-version grant. +- The import path should be `third_party/libowfat`, with a normal CMake target + such as `OWFAT::owfat`. Treat it like yyjson: bundled and required for the + feature that uses it, not an optional system probe and not only a reference + note. + +Follow-up: + +- Import/pin libowfat under `third_party/libowfat` in its own dependency patch. +- Add `third_party/libowfat/README.mars-nwe.md` documenting source/version, + GPL-2.0-only license, local CMake changes, and consumers. +- Provide a real CMake build exposing `OWFAT::owfat`; do not keep the original + Makefile as the long-term mars-nwe build path. +- Wire the tinyldap-derived standalone and mars-nwe `nwdirectory` builds to that + target. Keep direct libowfat usage scoped to the tinyldap compatibility layer + and do not spread it through unrelated NCP endpoint/provider code. + #### Source/header subtree layout migration Current status: diff --git a/third_party/README.md b/third_party/README.md index 5564f64..0eafdfa 100644 --- a/third_party/README.md +++ b/third_party/README.md @@ -22,6 +22,37 @@ 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: + +```text +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