Logos Forum — adversarial security audit

needs attention

No rate limit or cost gate on the one message type the engine accepts without a signature

core/src/engine.cpp's receive() tries to decode every incoming payload as a signed Post first. When that fails, it checks whether the payload looks like one of three small control messages. The first, tagged logos-forum-want, is a peer saying "here's how many posts I have, tell me if you have more" — and the engine's own comment explains why it carries no signature: "it carries no authority, only a place to look, and everything fetched from there is verified post by post." That's the right call for authority. It says nothing about cost, and the handler doesn't gate cost either:

if (a.is_object() && int_at(a, kWantTag) == 1 && str_at(a, "forum") == forum_) {
    const int64_t theirs = int_at(a, "have");
    const size_t ours = store_.count(forum_);   // real SQL COUNT(*), runs unconditionally
    const int path = str_at(a, "via") == "delivery" || !on_history_wanted ? 1 : 0;
    const uint64_t every = path == 1 ? kDeliveryAnswerEveryMs : kAnswerEveryMs;
    const bool quiet = !answered_[path] || now_ms >= last_answer_ms_[path] + every;
    if (quiet && !pending_ && theirs >= 0 && static_cast<size_t>(theirs) < ours) {
        // ... schedules a new pending answer, gated by `quiet`
    }
    return false;
}

The quiet cooldown gates whether a new answer gets scheduled — it does not gate the store_.count(forum_) call above it, which runs for every single incoming want, cooldown or not. There is also no per-sender or global rate limit on this message type at all; limiter_ (the token bucket) is only ever consulted in pump(), for what the node itself sends, never on receive.

Built probe_want_flood.cpp against the real, unmodified core/ library (no Qt, no mocked Store or Engine) to measure this directly rather than estimate it: seeded a real SQLite-backed store with 20,000 genuine signed posts, generated 5,000 distinct, unsigned want messages (plain string concatenation, no signature or proof-of-work computation needed), and fed them through the real Engine::receive().

In absolute terms, ~0.9ms per message against a 20,000-row table isn't itself alarming — this is a small, local-sync-oriented app, not a large public forum backend, and real forum sizes in its own e2e logs are tiny (single digits to dozens of posts). The finding is about the shape of the gap, not a proven DoS at today's scale: there is exactly one message type in this protocol that any peer can send, with no identity check and no cost, that the engine answers with guaranteed real work every time, and nothing in the code currently bounds how often one peer (or many) can do that. If forum sizes or peer counts grow, or if this ever runs where an attacker controls many Delivery identities cheaply, this is the one place that scales with attacker effort rather than being capped by it.

Suggested fix: apply the same per-path cooldown that already gates scheduling a new answer to the store_.count() call itself — e.g. skip the count entirely when !quiet, since the count's only use is the comparison the schedule-gate needs. That turns the unconditional per-message cost into a bounded, per-cooldown-window cost, consistent with how the sibling kAnnounceTag and kSnapshotTag paths are already bounded.

clean

SQL injection

Read all 24 query strings in core/src/store.cpp. Every one is parameterized through the Stmt wrapper's bind methods (.text(), .i64()); none build SQL by concatenating attacker-controlled strings. No injection found.

clean

Storage-CID announcements (kAnnounceTag)

Gated by asked_.find(re) — only acts on CIDs this node itself requested via a prior want. An unsolicited announcement from an uninvolved peer is dropped before any Storage fetch happens. Same self-limiting shape as Forumer's handleMediaHere, which the companion Forumer audit confirmed safe on the same reasoning.

clean

History-bundle answers (kSnapshotTag)

Bounded by kMaxSnapshotPosts = 100000. Not independently reproduced with a real oversized payload — this sandbox has no way to construct a Delivery-transported message anywhere near that size — but the bound itself is generous enough, and Delivery's own per-message size cap sits far below what 100,000 encoded posts would need, that this is judged a secondary, likely-unreachable concern rather than a live gap.

clean — no feature exists

Image / media path

This audit specifically checked for an image/media path. Searched src/ and core/ for anything resembling image handling, file attachments, or media references — found nothing. This app has no such feature at all, so there is nothing in this category to audit — stated plainly rather than silently skipped.

clean

Crypto handling

Signing and verification both go through libsodium's crypto_sign_detached/crypto_sign_verify_detached over a canonical, domain-separated byte serialization (not raw field concatenation, which would be vulnerable to ambiguous re-serialization). Secret key material is wiped with sodium_memzero on rotation and immediately after one-time anonymous signing — confirmed by reading identity.cpp directly, not assumed from the function names.