Audit of the public repo against the actual server and konduit-ctl source.
The happy path was documented; the failure modes were not.
- server.toml had no reference at all. Add docs/server-config.md covering
every key, [tls], the control API, and key handling.
- The mantra could not recover the identity key on its own:
derive_from_passphrase needs the [kdf] salt, which is 32 random bytes
generated once at bootstrap. bootstrap says so in the file it generates
(core/src/config.rs:403); the quickstart claimed the opposite. Fixed, with
a backup step added before it is needed rather than after.
- konduit-server never appeared in a download step, yet
konduit-server.service expects /opt/konduit/konduit-server - a path no
instruction created. Added the install section and moved setcap after the
copy, since capabilities do not survive every cross-filesystem copy and a
binary that silently lost cap_net_bind_service fails at bind time.
- Hot config reload was a headline feature with no documented mechanism. It
is a control API on 127.0.0.1:3001, and add-client only edits the file on
disk, so a new peer is not live until something reloads it. Documented,
including that /reload does not disconnect revoked peers but /sync does.
- [tls] native termination was entirely undocumented; the key must be PKCS#8.
- Dropped a README claim about a konduit-admin-ui unit that does not exist,
and fixed a systemd copy path that only resolved if this repo had been
cloned to /opt/konduit.
#k-ops/#1/#211
Three defects in the README, all found while cross-checking it against the
source and the published releases.
## 1. The key-storage claim was false, not merely wrong about platforms
"Private keys are stored in the OS secure enclave on every platform (iOS
Keychain, macOS Keychain, Android Keystore). They are never written to disk
in plaintext."
There is no OS-keychain integration in Konduit at all. Nothing in the Rust
workspace or the Flutter GUI references a keyring or secure-storage crate --
the GUI's only persistence dependency is shared_preferences. And
core/src/config.rs writes the client identity key straight into the config
file the docs tell you to pass with --config:
client.toml: identity_key = "<hex>"
so "never written to disk in plaintext" was false by construction, for the
one thing the claim was about. It also named two platforms that do not ship.
Replaced with what actually happens, and the consequence: the key is
generated locally, never sent to K-Ops, and the config file is itself the
secret -- so restrict its permissions, do not commit it, do not paste it
into a bug report. Deliberately not reworded into another claim I could not
verify.
## 2. The CLI example does not run
./konduit connect --config client.toml
--config is a top-level flag on Args (cli/src/main.rs:15), not on the
Connect subcommand, and it is not marked global, so clap rejects it:
error: unexpected argument '--config' found
Fixed to `./konduit --config client.toml`, which is the form
docs/client-quickstart.md uses and the binary accepts. Documented the
`connect` subcommand's actual flags --server/--peer-id/--identity/
--server-pub -- checked against `konduit connect --help`.
## 3. The artifact table lists assets that are not in the current release
Checked against the Gitea releases API rather than the Makefile. v0.1.0-beta.11
ships five assets: the AppImage, the three Linux binaries, and
konduit-gui-...-windows-x86_64-portable.zip. It has no Windows CLI zip and
no Android AAB; beta.9 and beta.10 had both, and the Windows GUI zip was
only named -portable.zip in beta.11.
So the Windows GUI row is now the published name, and the two rows that
appear in some releases but not others are marked as such with the
variation spelled out. The Releases page is called authoritative, since
which assets ship is a per-release decision.
No claim here is reworded from assumption -- each one was checked against
the code or the published release first.
