Targetcore verifies peer identity and encrypts its connections BY DEFAULT since 2026-08-18. A hub that is not provisioned to do that no longer starts.

This reverses the posture this file carried until then, and it is a breaking change. Before it, authentication was opt-in and off, which meant a hub verified nothing unless somebody remembered to ask — so the deployments that most needed it were exactly the ones that never called RequireAuth.

What changed, precisely:

• RequireAuth now defaults to true. A login must carry an ECDSA P-256 signature bound to the connection it arrived on, and the session is AES-256-GCM sealed under an ephemeral ECDH key.
• A hub that requires auth and cannot enforce it refuses to arm. CreateHub() returns FALSE and SpawnHub() returns 0, and the refusal names the file that is missing. The flip on its own would have been worse than the old default, not better: a hub that requires auth and holds no keys does not refuse an attacker, it refuses everyone, at the first peer's login — which in practice means at 3am, to whoever did not do the deployment. The gate moves that failure to the deployment.
• The migration is one line. Either provision the hub (see Turning peer authentication on below — ProvisionAuth() makes the identity and prints the fingerprint to publish), or call RequireAuth(false) before arming and mean it. What is no longer possible is turning it off by saying nothing.
• Since 2026-08-21 the gate also asks about revocation, and this half is a bigger break. RequireRevocation defaults to true: a hub that requires auth must either name a revocation list or say RequireRevocation(false), and one that does neither does not start. Step 8 refused a hub that would have refused every peer anyway; this refuses one that works. It is worth the break because revocation is the only mechanism here for withdrawing trust already granted — rotation and the allow-list only ever add — so a hub with no position on it can never answer "this key is compromised". Turning the requirement off does not turn revocation off: a list named anyway is still loaded, still enforced, still fails closed.

RequireAuth(false) is a supported answer, not a defeat: a hub on a trusted segment, an in-process router, a test that is not about authentication. Covered by p2p_armgate, which includes the opt-out as a required phase — if the migration did not work, this change would be an outage rather than a default.

Do not expose an unconfigured Targetcore endpoint to a network you do not control. The configured path has not been externally audited, so treat it as defence in depth behind a tunnel rather than as a substitute for one.

If you host a hub inside a Windows service, set P2PMSG_NO_UI=1 in its environment. Fixed in code on 2026-08-17 — no longer required. The problem it worked around: a library diagnostic is written as text when there is somewhere to write it, and raised as a MessageBox when there is not. A service started by the SCM has neither a console nor a standard error, so the dialog went up on whichever thread produced the event — for a routing or connection diagnostic, the hub's own pump thread. Nobody can dismiss a dialog in a non-interactive session, so the pump never returned, never saw the CLOSE signal, and CloseHub() waited for it indefinitely; that wait is unbounded by design, because bounding it would trade a hang for a use-after-free.

P2PeventUseTextOutput() now asks whether anybody could see a dialog before it asks whether there is anywhere to write one — ProcessIdToSessionId for the isolated services session, and WSF_VISIBLE on the process window station. A service fails both and never reaches the dialog branch, with no configuration at all. A windowed application is in session ≥ 1 on a visible station, so it is unaffected and keeps its dialogs. P2PMSG_NO_UI=1 still works, and P2Pevent::ForceTextOutput(true) is the same switch from code, for a windowed host that wants no dialogs from the library at all. P2PeerService sets it for a hosted hub either way.

Refusing the dialog is half the fix; the other half is a destination, or the diagnostic is written to a handle that is not there and a defect that used to hang loudly disappears quietly. In service mode P2PeerService routes diagnostics to the Windows application event log under the service's own name, registering the source in Install(). P2Pevent::SetTextSink() is the hook if you want them somewhere else. Worked example: _Targetcore_UseExamples/ErrorReportingExamples/NTServiceEventLog.

A plain text file beside the host executable, P2Pmsg.cfg, says the same two things without code — ErrToMessageBox: 0 to refuse the dialog and LogFile: <name> for the destination, defaulting to errorLog.txt. Read this part before deploying one, because both rules exist to stop the file becoming an attack on availability rather than a convenience: ErrToMessageBox: 1 cannot put a dialog back where one would hang — the setting moves only towards text, and cannot cancel P2PMSG_NO_UI, ForceTextOutput(true) or the viewability test — and LogFile loses to an installed sink, with a relative path resolved against the configuration file's own folder rather than the working directory, so a file dropped beside an executable cannot divert a service's diagnostics out of the event log and into %SystemRoot%\System32. Anything the parser cannot read is ignored and reported through P2Pevent::ConfigDiagnostic(); neither default is ever guessed at. Worked example: _Targetcore_UseExamples/ErrorReportingExamples/DialogOrLogFile.

Appropriate use today:

• Loopback and single-machine inter-process messaging — and since 2026-09-04 P2PeerConPipe enforces it. CreateListenPipe passes PIPE_REJECT_REMOTE_CLIENTS, which keeps the SMB redirector out, and an explicit protected DACL — D:P(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;OW), the same three ACEs the identity file gets — in place of the platform default that granted Everyone and Anonymous read access. The client opens with SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION, so a server squatting the pipe name is handed the client's bytes and not its token. The server side of squatting is refused too: a named pipe keeps the descriptor its first instance was created with, so a local principal who created the name first would have had this transport join their pipe while the class still read Local. The first instance CreateListenPipe makes therefore passes FILE_FLAG_FIRST_PIPE_INSTANCE and a name that already exists fails, ERROR_ACCESS_DENIED, with a diagnostic naming the holder; the re-arm after an accept is a second instance of the transport's own pipe and does not pass it. Such a pipe answers TrustClass() == Local and its hub may relax it with SetLinkPolicy(P2PeerConTrust_Local, P2PeerLinkPolicy_Open) (THREAT_MODEL.md F-SR-1, now closed)

• The old pipe is still reachable, by name. SetPipeAccess(P2PeerConPipeAccess_Legacy) on the service connection reproduces the pre-2026-09 CreateNamedPipe byte for byte — no reject, null descriptor — for a deployment that shares a pipe between a service account and an interactive user, or reaches one over SMB. That pipe is a wire and reads Wire, which is the point: the compatibility escape hatch is precisely the one that does not get to claim the class. SetPipeAccess(P2PeerConPipeAccess_Descriptor, sddl) is the middle — the reject stays, the caller supplies the DACL

      // this account only, no remote clients, and the class says so
      P2PeerConPipe *pSvc = P2PeerConPipe::ServiceFactory ( L"App.*", L"\\\\.\\pipe\\MyApp" );
      oHub.SetLinkPolicy ( P2PeerConTrust_Local, P2PeerLinkPolicy_Open );
      oHub.PostP2PeerCon ( pSvc );        // pSvc->TrustClass() == Local

  On Linux the pipe is an AF_UNIX socket and there is no equivalent of a pipe over SMB, so the class is a property of the address family and holds in every mode; what has no counterpart there is the DACL, and access control is the 0700 directory plus the process umask

• Trusted LAN segments and lab networks

• Directly attached hardware buses (P2PeerCon232, P2PeerConDmx)

• Research, teaching, and modernisation work on the codebase itself

Not appropriate today:

• The public internet
• Any network segment carrying untrusted peers
• Any deployment where message authenticity or confidentiality matters
• Anything handling personal data, credentials, payments, or safety-critical control

The analysis behind this table — the adversaries each row answers, the assets they defend, and what is deliberately out of scope — is THREAT_MODEL.md. This file is the operator-facing half: what the defaults are, how to turn things on, and how to report a vulnerability.

The legacy DHKeyXChanger and Rijndael sources have been deleted from the tree. Neither was ever reachable and neither was ever constructed, but a reader who opened them reasonably concluded they were the security story — which is the harm a comment cannot undo. Their defects stay on the record here and in the project's internal engineering log so nobody re-adopts them; the code itself is recoverable from git history if it is ever wanted. Deleting DHKeyXChanger closed M7, the unbounded pre-auth bignum parse, which existed in two divergent copies.

On by default since 2026-08-18. What you are configuring is not whether to require it — that is already true — but whether this hub can. Configure before SpawnHub()/CreateHub(); a hub that requires auth and is not provisioned will not start.

    oHub.SetIdentity  ( "/etc/p2p/peer.key", /*create if absent*/ true );
    oHub.SetAllowList ( "/etc/p2p/peers.allow" );
    //  RequireAuth(true) is the default. Say it if you like it in writing.

There are two files and only one of them is mechanical. ProvisionAuth() does that one:

    char szFingerprint[p2pcng::kIdFingerprintLen] = {0};
    bool bCreated = false;
    oHub.ProvisionAuth ( "/etc/p2p/peer.key", szFingerprint,
                         sizeof(szFingerprint), &bCreated );
    //  -> creates peer.key if absent, loads it if not
    //  -> writes peer.key.pub, the line to paste into every peer's allow-list
    //  -> hands back  5FAD-2289-0652-A76C-E9B8-9B23-06A0-0A2C  to read aloud

Run it twice and the second run finds the key rather than replacing it — a first-run helper that regenerated on restart would rotate every hub's identity behind the operator's back, and every peer holding the old point would stop being able to verify it.

It deliberately does not create the allow-list or the revocation list, and the hub still refuses to arm until you have dealt with both. Who to trust is the half of provisioning that is not mechanical, and a library that silently created an empty allow-list would be answering it — with "nobody", which refuses every peer.

[ERROR] []P2PeerHub::SpawnHub()
P2PeerHub(Acme.Gateway) will not arm: allow-list unreadable - missing, or a line that will not parse
ADVICE  : Auth is required by default (Stage 3 step 8). Provision this hub, or
          RequireAuth(false) and mean it.  Allow-list: /etc/p2p/peers.allow

Seven distinct reasons since 2026-08-21, all reported through the same channel and all available as a return value from P2PeerHub::AuthArm() before you arm anything: no identity, no allow-list, an allow-list that cannot be read, an allow-list that names nobody, no revocation list, a revocation list that cannot be read, and ArmNotRequired for a hub that opted out. The empty allow-list is its own case on purpose: it is the state an operator reaches by accident, it loads without error, and it refuses every peer exactly as having no file would.

The advice and the file named both follow the reason, which they did not have to before there was more than one candidate — sending an operator to the allow-list when the revocation list is the problem would be worse than naming nothing, since the two sit in the same directory under similar names:

[ERROR] []P2PeerHub::SpawnHub()
P2PeerHub(Acme.Gateway) will not arm: no revocation list - SetRevocationList(path), or RequireRevocation(false)
ADVICE  : No revocation list, so no key could ever be withdrawn. Name one, or
          RequireRevocation(false).

One line per hub, and it must be an explicit one:

    oHub.RequireAuth ( false );   // trusted segment / in-process router / not under test

• The private key never leaves the peer that generated it. Publish only the public half — ProvisionAuth() writes it as <key>.pub, SavePublicKey() writes it on its own, and Fingerprint() prints it for comparison over a phone call. An allow-list line is <address> <hex public point>, and the address must be the one the peer will claim at login, exactly: an entry is not a pattern, and Peer.* in that column admits nothing.

• RequireAuth is a hub property with no per-connection override. That is deliberate — it is the one setting that must not be losable when an accepted connection is built from the listener. It stays true after SetLinkPolicy below, and the distinction is the whole reason that call is allowed to exist: what moved to the connection is a classification, not a permission. A transport answers TrustClass() — a fact about where its frames can go, a virtual on the class, and therefore nothing AcceptSpawn can fail to copy — and the hub still decides, in one place and under its own lock, what a link of that class must do.

• SetLinkPolicy(class, policy) is what a link that cannot benefit from the handshake pays instead. A DMX connection is a pointer handoff between two objects on one heap, and under RequireAuth(true) it ran a full ECDH agreement, held a BCrypt key object that is never consulted, and signed four ECDSA operations onto its login — to protect a channel with no wire on it. RequireAuth(false) was the only way to say so, and it opens every link the hub will ever hold, including a socket posted to it later.

      oHub.SetLinkPolicy ( P2PeerConTrust_InProcess, P2PeerLinkPolicy_Open );  // DMX
      // ...and a TCP link on the same hub is untouched.

  Three classes: Wire (0, the default for every transport that has vouched for nothing — a serial line, a socket that is not on loopback, and a named pipe asked for P2PeerConPipeAccess_Legacy, which accepts a client arriving over SMB from another host), Local (1, the kernel keeps it on this machine — a loopback socket, and since 2026-09-04 a named pipe this transport created), and InProcess (2, construction keeps it in this process). Wire cannot be opened — the call is ignored — because a wire is what an unexamined transport answers, so opening it would relax the whole tree through a call that reads as though it named one kind of link.

  Local is not trusted: it says no network adversary can reach the link, and nothing about another principal on the same host, who reaches a loopback port exactly as easily as this process does. Both ends need the same setting, as with RequireAuth, and since 2026-09-04 that is enforced in both directions: a peer that skipped the agreement against a hub that wanted one is refused at the login gate, and a peer that opens an agreement against a hub that has relaxed the class is refused at KeyXOnRequest — before it runs, rather than after, when the disagreement used to surface as a login block handed to the application. A hub with RequireAuth(false) is untouched by the second half and still services an exchange, as it always has. And it is a per-link setting only — relay attestation and end-to-end sealing are properties of an origin and a destination rather than of one hop, so an opened link still signs and still seals.

  Every class defaults to Full, so a hub that never calls this behaves exactly as it did.

• RequireTrustAtLeast(class) is the other half of that call, and it is what makes the opt-out safer than RequireAuth(false) rather than merely cheaper. A hub that has opened its in-process links is one PostP2PeerCon away from carrying a socket it did not plan for. That socket authenticates in full — Wire is Full and cannot be set otherwise — so nothing is weakened; what happens is that a hub which exists to route inside a process quietly becomes a network endpoint, and no field anywhere says so. The fence refuses it instead, at the moment it is offered, naming the class:

      oHub.SetLinkPolicy       ( P2PeerConTrust_InProcess, P2PeerLinkPolicy_Open );
      oHub.RequireTrustAtLeast ( P2PeerConTrust_InProcess );   // ...and nothing else, ever

  It is measured against EffectiveTrust(), so a connection an operator demoted is judged on the class they demoted it to. Wire — the default — means no fence. An accepted child does not pass through PostP2PeerCon; it does not need to, because it is spawned by a service the fence already admitted and cannot read a higher class than that service.

  It also changes what arming means for one shape of hub. A hub that requires authentication, has fenced out every class it will not carry and has opened every class it will, can never demand a signature from anybody — so it arms with no identity and no allow-list, reporting p2pauth::ArmNotRequiredByPolicy rather than refusing to start for want of a key it will never use. That is not quiet: the posture still reads AuthRequired=1 beside TrustFloor and the three LinkPol fields, which is what makes it a stated decision rather than the omission the arming gate exists to catch. Take either half away — a class above the floor still Full, or the floor removed — and it reports ArmNoIdentity again.

• WaiveEndToEndInProcess(true) is the only switch that reaches the end-to-end cost, and it is the only one in this file whose correctness rests on an assumption rather than a mechanism. SetLinkPolicy above relaxes a hop; the two end-to-end protections are properties of an origin and a destination, so an opened link still signs and still seals — and that is not a technicality. Measured (p2p_linkcost, five postures, three runs): the default posture costs 14× the CPU per message of the same chain with nothing on, 93% of it is the seal and the attestation, and SetLinkPolicy(InProcess, Open) recovers none of it. This switch is what that measurement was taken to decide.

  It waives the seal and the relay attestation when the destination is a hub this process holds, which is a registry lookup and an exact address match — a hub Alice here says nothing about Alice.Bob, which may be a child hub on another host.

      oHub.WaiveEndToEndInProcess ( true );   // off by default

  Read the assumption before turning it on. It holds only if a message to an in-process hub never transits an out-of-process one — true of a tree whose in-process hubs form one subtree, and not guaranteed otherwise. The failure mode in full, because a paraphrase is not enough to decide by: hubs A and C in one process, B on another host, wired A-B-C. A sends to C, C is in this process, so nothing is sealed or signed — and the body crosses the wire to B in clear, because the destination being local is a fact and the route staying local is not. Nothing in the library can tell those two apart, which is why this is opt-in: the assumption becomes something an operator wrote down rather than something the library made on their behalf.

  It waives nothing for a broadcast (a scope names a subtree, and a subtree cannot be shown to be in this process even when its root is — that is RequireSealBroadcast's decision), and the receive-side exemption in GateRelayInbound keys on the same registry lookup, never on the link's trust class: keyed on the class, a remote ancestor could forward an unattested message down an in-process link and be admitted. TryReadPosture reports it as WaiveE2E, so a hub reading SealRequired=1 beside WaiveE2E=1 — requires sealing, does not always do it — is legible without reading the source. Gated by p2p_e2ewaive, falsified three times.

• SetIdentity alone makes a hub sign; RequireAuth makes it demand. A peer that signs to a hub which does not require authentication has its block handed to the application, and the stock On_ConLogin refuses the payload loudly. Configure both ends.

• Reloading: ReloadAllowList() is valid on a running hub, so adding a peer is not a restart. A file that fails to parse leaves the previously validated list in place.

Clock. The login carries a timestamp, and a login outside ±300 s of the server's clock is refused. Peers therefore need loosely synchronised clocks — NTP, a domain, anything that holds them within a few minutes. Rejections are logged with the measured skew and its sign, so a wrong clock is a one-line diagnosis rather than a mystery; the server's time is deliberately not returned to the peer, which has proven nothing at that point. Note that a clock which jumps — a VM resumed from a snapshot, a laptop opened after a week — will refuse logins until it resynchronises.

The window is a memory-and-clock parameter, not the replay defence: replay is stopped by a per-hub cache of nonces already seen, and the timestamp only bounds how long that cache must remember. SetAuthWindow(0) disables the freshness check for devices with no clock at all (RTC-less hardware on the serial and DMX buses). That is a real trade and worth stating plainly: with no window the cache can no longer be trimmed by time, so it is bounded by capacity instead, and a nonce evicted by capacity becomes replayable.

The channel. RequireAuth(true) also turns on the session cypher — the two are one switch on purpose, because a confidential channel to an unproven peer and a proven peer on a readable wire are each half an answer. Every connection runs its own ephemeral ECDH P-256 agreement before the login:

  1  client -> server   client_pub      plain
  2  server -> client   server_pub      plain    both ends derive the key here
  3  client -> server   login           sealed
  4  server -> client   login ack       sealed

The shared secret goes through HKDF-SHA256 to an AES-256-GCM key, and everything from flight 3 onwards is sealed. There is no cipher negotiation and no version to downgrade to. The login signature covers SHA-256("P2P-kx-v1" | client_pub | server_pub), which is never transmitted — both ends compute it from the two public halves — so a proof made for one connection cannot be replayed onto another.

What this does not do. Forward secrecy is per connection, not per message: the session key lives as long as the connection, so compromising it exposes that whole session. There is no rekeying. And this paragraph used to end "none of this is on unless you switch it on — an unconfigured hub is byte-identical to a build without any of it", which has been false since 2026-08-18 and is corrected here rather than deleted: the session cypher rides on RequireAuth, RequireAuth defaults to true, and a hub that cannot enforce it does not start. The build that is byte-identical to one without any of this is the one that says RequireAuth(false) out loud.

And it does not hide anything from a hub. The session cypher protects one hop. On a route A → B → C, hub B decrypts A's frame, decides where it goes from the destination address, and re-seals it for C. B sees the plaintext, and no amount of link crypto changes that — a hub that could not read the frame could not forward it. That is what the next section is for.

Independent of RequireAuth, and a different question: not who is on the wire but who can read the message. Seal the payload to the destination itself and leave the addresses in clear, so every hub can still route and none of them can read:

    oHub.SetIdentity     ( "/etc/p2p/peer.key",   /*create*/ true );  // to sign with
    oHub.SetAgreementKey ( "/etc/p2p/peer.agree", /*create*/ true );  // to be sealed to
    oHub.SetAllowList    ( "/etc/p2p/peers.allow" );

    size_t cbOut = 0;
    std::vector<unsigned char> vSealed ( p2pseal::SealedSize ( cbBody ) );
    oHub.SealFor ( L"Me", L"Them", pBody, cbBody,
                   &vSealed[0], vSealed.size(), &cbOut );

• Two keys per peer, and they are not interchangeable. The ECDSA identity key proves who you are at login; the ECDH agreement key is what others seal to. Separate files, separate container magic, separate DPAPI entropy — using one key for two algorithms is a standard way to turn a signing oracle into a decryption oracle.

• The allow-list grew an optional third column: <address> <identity hex> [<agreement hex>]. Existing two-column files keep working unchanged, and a peer with no agreement column can still log in — it just cannot be sealed to. Asking to seal to it returns SealErrNoAgreement. There is deliberately no fallback that sends the body in clear because the directory was incomplete.

• A sealed body costs 156 bytes — eph_pub(64) | nonce(12) | ct | tag(16) | sig(64). The source and destination addresses are bound in twice, as GCM additional data and inside the signed transcript, so a body lifted off one message and pasted onto another does not open.

• A key can now be replaced, and withdrawn. The allow-list may carry more than one line for the same address and every key listed is tried, so a peer is issued its next key before it starts using one and cuts over on its own schedule — no instant in which one side has rotated and the other has not. A separate revocation list overrides the allow-list:

      peers.allow                                  peers.revoked
        alice  <old-id-hex>  <old-agree-hex>         <old-id-hex>  1760000000  # rotated out
        alice  <new-id-hex>  <new-agree-hex>
  

  It is keyed on the full 64-byte point, not the fingerprint — Fingerprint() says in its own contract that it is never an identifier the code trusts, and refusing a peer is exactly the code trusting one. One file covers both key kinds, because with two an operator can revoke a compromised peer for login and forget sealing. ReloadRevocationList() works on a running hub, which is the only way revocation helps during an incident, and a configured list that cannot be read fails closed rather than reverting to "nothing is revoked" — deleting the file to turn revocation off would otherwise silently re-admit every key you had withdrawn. Guarded by p2p_keyrotate, whose fourth phase is a liveness control: without it, "the revoked key was refused" and "the server fell over" are both silence.

• A peer that seals also signs its logins, because SetIdentity is what both need. Every hub it connects to must therefore either require auth or implement an On_ConLogin that accepts a login carrying data — the stock handler refuses one.

• A Windows peer and a Linux peer can actually do this to each other, which is a separate claim from either backend working, and is now tested rather than asserted. The seal_interop test opens bodies sealed by the other backend from checked-in vectors (MscsUnitTests/vectors/), covering the two places the two builds could silently disagree: the address transcript — wchar_t is 2 bytes under MSVC and 4 under GCC, and the addresses sit inside both the GCM additional data and the signature, so the vectors carry an address with a Cyrillic character and one outside the BMP, exercising the surrogate-pair path only Windows takes — and the 96-byte X||Y||d private blob, which CNG exports and the OpenSSL backend reimplements. The identity container is checked the same way, since provisioning ships those between machines.

What rotation and revocation do not do. Rotation is operator-driven: it removes the flag day, not the provisioning step — someone still has to put the new key in front of every hub that trusts the peer, and until they do, that hub knows only the old one. There is deliberately no signed rollover certificate, because a peer that can mint its own replacement key hands whoever steals the old private key the ability to mint one too, silently, and revocation then has to win a race it did not start. Nothing distributes the revocation list either: each hub reads its own local file, so a revoked key is refused exactly by the hubs that have been given the update. And revocation is absolute rather than time-scoped — the timestamp column is a record, never compared against a clock, so there is no validity window to move a key back inside.

What this does not do. No replay defence and no freshness: a sealed body is valid forever and can be delivered twice, because ordering and liveness belong to the layer that knows what a duplicate means for its own messages. The ephemeral half gives forward secrecy against later compromise of the sender, but not of the recipient — whoever holds the recipient's agreement key can open every message ever sent to it. And the addresses stay in clear by construction: this hides the body, never the traffic pattern.

Security work is tracked in the open. In priority order. These numbers are referenced from the project's internal engineering log, which is not published in this repository, and are stable — they are not renumbered. This list stays the source of truth for the security argument behind each item.

1. Binding a message's source address to the identity its connection logged in as. ✅ Done on a link to a descendant and on a link to an unrelated peer, guarded by p2p_authspoof. A link to an ancestor is deliberately exempt and carries no source check. Closing that exemption needs per-branch route knowledge, or an attestation from the relaying hop, neither of which exists. ✅ Done — as the attestation, not the route knowledge. RequireRelayAuth(true) makes a downward relay carry the origin's ECDSA signature over its addresses, message name and body digest, and the at-or-below test is then applied to whoever signed rather than to whoever delivered. Guarded by p2p_authancestor, which now asserts the protection. Still outstanding from this item: on by default, which needs every hub in a tree provisioned with its neighbours' identities. ✅ On by default since 2026-08-18. It does not need every hub provisioned, which is what that sentence assumed and is wrong: only the hub that verifies needs the origin in its allow-list, and only the origin needs an identity. Every relay in between can hold nothing at all — which p2p_authancestor now demonstrates with two keyless relays and no switch set anywhere. And there is no replay defence. ✅ Added 2026-08-15, as RefuseRelayReplay(true) on the hub — a per-hub cache of the signatures it has accepted, so the same signed block delivered twice to one hub is refused the second time. It is keyed on the signature, not on the message, which is what lets it coexist with the reason there was no cache here before: a broadcast still reaches every hub, because the cache is per hub; and two legitimate sends of identical content still both land, because ECDSA signing is randomised, so they carry different signatures. That premise is asserted by the test suite rather than assumed, and it fails loudly if this tree ever moves to deterministic signing.

   Off by default, and this is the judgement it hands the operator: a hub that legitimately receives one signed block twice — a DAG rather than a tree, or an application that re-delivers on purpose — will see the second copy refused. Still outstanding: freshness remains the only bound on how long a captured block is worth replaying, and the cache is bounded by count as well as age, so a signature flushed by kSeenMax newer ones is replayable again even inside the window. That bound is deliberate rather than a shortcut — the cache is scanned once per block, so bounding it by age alone would have made the cost grow with the square of the relayed traffic and turned the protection into its own denial of service. The remaining exposure costs an attacker kSeenMax genuinely signed blocks through the same hub. Sealed bodies are a separate case and are not covered by this — see item 4.

2. Proving identity at login rather than asserting it. ✅ Done, as a per-peer ECDSA P-256 signature rather than the shared PSK first planned — a shared key proves membership, not identity, so every holder could still produce every other holder's MAC. Opt-in; on by default is the next step. Along with key rotation and revocation, which the current design has no answer for. ✅ Done — an allow-list may list several keys per address and every one is tried, and an overriding revocation list withdraws either key kind, reloadable live and fail-closed. Guarded by p2p_keyrotate. Still outstanding from that half: nothing distributes the revocation list between hubs. ✅ Added 2026-08-15, as a signed, versioned list one hub hands another — SetRevocationAuthority / IssueRevocationList / ApplyRevocationList. Until then the deny-list was a local file, so a compromised key was refused exactly where an operator remembered to type it and honoured everywhere else, which for a mesh of any size is close to not being revoked at all.

   Two properties carry the design. A received list is verified against the one named authority the operator configured, never against the allow-list, because a deny-list any peer can inject is a denial of service — one compromised peer would otherwise revoke the whole mesh. And it is merged, never substituted, so nothing that arrives can un-revoke anything: a stale, replayed or rolled-back list can only fail to add, which is the direction a security failure is allowed to point. Carrying a list is unprivileged — the signature is the trust, not the courier — so a revoked peer can still relay one. An authority that revokes itself is applied and then stops being the authority. A hub with no revocation file has nowhere durable to put a list and refuses it rather than accepting one it will forget at the next restart.

   Still outstanding from that half: rotation is operator-driven, there is deliberately no automatic gossip (when to publish and who to hand it to are routing decisions this layer does not own), and SetMaxRevocationStaleness is off by default — expiring on silence would turn a partition into a total outage, which is a better attack than most of what revocation defends against.

3. Wiring P2PCngCrypto (ECDH P-256 → HKDF-SHA256 → AES-256-GCM, CSPRNG key material, authenticated transcript) into the connection handshake ✅ Done, opt-in with RequireAuth(true), and the legacy DHKeyXChanger / Rijndael path is now deleted. Still outstanding from this item: per-message forward secrecy (rekeying), and on by default. ✅ On by default since 2026-08-18 - it rides on RequireAuth. Still outstanding from this item: per-message forward secrecy (rekeying).

4. End-to-end confidentiality, so a routing hub cannot read the bodies it carries. ✅ Done, opt-in, as SealFor/OpenFrom over ECIES plus a sender signature. Still outstanding: replay defence for sealed bodies. 🟡 Partly closed 2026-08-15, as RefuseSealReplay(true) — a recipient refuses a body it has already opened, keyed on the sender's signature.

   It is weaker than the relay refusal in item 1, and the difference is the design, not an oversight. A relay block carries a signed timestamp, so freshness refuses an old one and its cache only has to remember what freshness would still accept. A sealed body carries no timestamp and never expires, so an entry dropped for age would hand back exactly the replay it was holding — ageing that cache would not bound the memory, it would publish the waiting time. It is therefore bounded by count: the most recent bodies cannot be replayed to a given recipient, and an older one can. That stops capture-and-redeliver and does not stop a patient attacker. Closing it properly needs freshness inside the sealed transcript, which is a wire-format change to a block carrying no version byte, and is not done. A replayed body is decrypted before it is recognised, so the plaintext is wiped and the length zeroed before the refusal is returned — covered by its own case, since a caller that checks the length instead of the result must not find the message sitting in its buffer.

   Also still outstanding: forward secrecy against compromise of the recipient's agreement key. Key rotation — which the identity keys needed too — is now covered for both by item 2's revocation and multi-key work: an agreement key rotates by adding a second allow-list line and revoking the first, and SealFor skips a revoked agreement key rather than sealing to it.

5. Handle validation across the flat C ABI, ahead of the Java/Panama bridge. ✅ Done, as a type-aware, pointer-keyed registry of live handles that never dereferences the caller's pointer — reading a magic word through a hostile pointer is the defect the magic word was meant to fix. Every handle is registered where it is created and forgotten where it is destroyed, so a pointer the library never issued, a freed one, and one of the wrong kind are all refused (M1). Each entry point also catches P2Pevent rather than letting a C++ exception unwind across the extern "C" boundary, which an FFI downcall has no landing pad for.

   The surface was removed from this repository on 2026-08-13 for having no in-tree consumer, and restored on 2026-08-14 with the registry intact; it is built into the DLL and the .so again, and Targetcore_c.h is the single copy that the Java tree's bindings are generated from. Still open here: the Targetcore surface has no test of its own for the four refusal cases. ✅ Closed 2026-08-14. The nine cases deleted with the ABI were restored with it — a pointer the library never issued (including (void*)0x1, which faults any design that reads through the caller's pointer), a destroyed handle, a double destroy, wrong-kind confusions, a throwing callee, and a control proving the registry still says yes — plus the two p2peerhub_set_sink cases and the p2p_u8_smoke ctest entry. Msgcore_c.*, a separate flat C API still built into Msgcore.dll, carried the identical defect, got the same registry on 2026-08-13 across 217 entry points, and has its own four cases plus a control. Both are run on both platforms; the Linux half is not a formality, since the sink cases are the only things that execute the copy out of the accessor ring, which is a no-op on Win32 and load-bearing everywhere else. (This paragraph claimed the gap was open for a day after it was closed — the restore updated the report and not this file.) 5a. Bounding what an unauthenticated peer can hold. Numbered out of sequence deliberately — items 6 and 7 are referred to by number from that internal log, and renumbering them to make room would silently break those references. In priority order it sits here.

   Everything above decides who may speak. This is spent before a word is said, and until 2026-08-16 nothing bounded it in either dimension: no count of accepted connections, so the limit was the descriptor table, and no deadline on a peer that connects and never logs in. ✅ The count is done — SetMaxAccepted(n), default 1024, refused at accept with the socket closed rather than left in the backlog, guarded by p2p_acceptcap on both platforms. ✅ The per-source share is done too, on 2026-08-19 — SetMaxAcceptedPerSource(n), keyed on getpeername() at accept, off by default because loopback and NAT both collapse many peers onto one address. Guarded by p2p_srcbound. The pipe transport is still bounded by an nMaxInstances it does not own; see the posture row above. ✅ The deadline works on BOTH platforms since 2026-08-18. The mechanism was already complete in the tree — On_PITimer throws "Login timed out" on expiry and all three cancel sites are correct — and only the SetPITimer call arming it was commented out. Arming it turned up two defects: CancelP2PmsgTimer treated "already fired" as corruption and threw from ~P2PeerCon (fixed, and it had been reachable by the restart timer all along); and a Linux cascade in which the drop appeared to cancel the listening socket's pending accept. That second one is not fixed. That cause was wrong and was recorded in three places. Traced rather than assumed: the real fault was that closesocket() erased the fd→key association before the cancellations it triggered completed, so every ERROR_OPERATION_ABORTED arrived unattributable and the service read it as a failure of its own listener. Fixed by binding the key at submission (OVERLAPPED::_p2p_key). p2p_logindeadline is registered on both platforms and passes on both. DEF_P2PeerConLogin is still 0 — the cascade that forced that default is gone, but the deadline stays opt-in.

   Still outstanding: the Linux cascade above; the cap is per service, not per host or per source address — 1024 connections from one peer and one each from 1024 peers are the same thing to it, because the address is not known until the login that has not happened; and the cap is enforced in P2PeerConWsa alone, so the pipe, serial and DMX transports rely on bounds they do not own (nMaxInstances, physical ports) rather than on this one. Recorded 2026-08-17.

   Two further resource questions are now on the record in the posture table rather than here, because both predate this item and neither is about an unauthenticated peer: the pump depth bound and its three disagreeing thresholds, and the diagnostic path that can block a pump thread in a service. Both were found on 2026-08-17 while re-answering the readiness question, both are read from the source rather than driven. and the second one is why every service host needs P2PMSG_NO_UI=1. The second was fixed the same day — a service host needs no setting at all, because the library now refuses a dialog wherever one could not be seen. P2PMSG_NO_UI=1 remains available, and so does ErrToMessageBox: 0 in P2Pmsg.cfg, for a windowed host that wants no dialogs at all.

6. Systematic fuzzing of the receive/framing path. CLOSED 2026-08-20. Fuzzing now runs continuously - daily, on both platforms, from a seed that moves with the run number and is still not the clock - against a persistent corpus that every gate run replays, at sizes spanning the receive ceiling rather than only the ~2 KB band it used to, and covering the authenticated wire parsers (p2p_fuzzblock: login, ack, relay attestation, revocation list) as well as the framing path. A finding arrives as a reproducer file rather than as a log line, which is the difference between a defect somebody has to re-derive and one that can be replayed with a single argument and promoted into the corpus as a permanent regression pin.

7. An external audit once the above land.

A written threat model — added to this list on 2026-08-20 and closed the same day, because it was never a numbered item and should have been. The arguments in this file were always about threats and were argued well; they were scattered, and scattered arguments cannot be checked for coverage. THREAT_MODEL.md puts them in one place — seven adversaries, nine assets, five trust boundaries, every protection mapped to the adversary it answers and the line that enforces it — and the mapping found three gaps on its first pass. All three are now fixed (F-S6-1, the posture table's channel-binding row; F-S6-2, a running hub that could not be asked what was on; F-S6-3, confidentiality inherited from a class rather than enforced by a rule), each with a gate test of its own, and each falsified against the tree that had the gap before it was believed. Closing the third opened F-S6-4 — a warning class that was masked out by default, so every EVWRN diagnostic in these repositories was raised into nothing — which was named in §8 of that document as an operator-facing default decision rather than a defect in a protection. That decision was taken on 2026-08-20 and the answer was to turn it on: the default notification mask is now ERROR|WARNING. The three warnings it makes visible are all operator misconfigurations with the fix in an Advice line — a relay attestation that could not be signed, a peer signing logins to a hub that does not require them, and P2PeerioBSTR (the transport that carries cleartext) being constructed — and all three report through SetLast(), so a misconfigured hub costs one line per connection rather than one per message. It is a behaviour change for every existing host and is recorded as an unreleased break; the opt-out is one call, P2Pevent::Configure(P2PeventCfg_REMMASK, P2Pevotn_WARNING). Item 7 is unaffected: a threat model written by the people who wrote the code is not an audit, and this one says so.

Until items 1-3 are complete, the warning at the top of this file stands unchanged.

This project is under active modernisation. Security fixes land on master only. There are no maintained release branches and no backports.

Including v3.1.1, v3.1.0 and v3.0.0. A tag is a point you can build from and trace a binary back to, not a branch anything is maintained on — if a fix lands after it, the fix is on master and the tag does not move.

The pre-1.0 disclaimer has been retired, by a decision rather than by a number moving past it. The versioning policy listed what had to be true before it could go, and three of the five items were security work: a written threat model, F-S4-1 settled (on Windows the accept bounds counted connections ever accepted, so a documented bound did not bound), and this sentence retired deliberately. All three are now met - the threat model is THREAT_MODEL.md, F-S4-1 was closed on 2026-08-20, and the disclaimer was retired with the 3.0.0 release on 2026-09-02.

What the release number does not settle, stated here because a major of 3 invites the assumption. 3.1.1 covers the flat C ABI and nothing else. The message image is still unversioned - its header has no version field and no spare bit - so a peer meeting a re-laid-out message parses garbage rather than reporting a mismatch. Targetcore_version.h says so at the point the number is set, and that is the statement to read before assuming the major covers more than it does.

F-S5-3's wire-layout question stood here too until 2026-08-20, and it closed by neither of the two routes gate 1 was written to expect. Not by re-laying the packed message image, and not by accepting the alignment exception as permanent. Re-diagnosed, the finding was not wide payloads are unaligned but every blob payload is - the image is #pragma pack(1) end to end, so a payload's offset is the running sum of odd-sized headers and no field ordering recovers it. It was answered by making the contract explicit and giving callers an aligned way to read: P3PmsgData::c_vBlobCopy, P2Pc_vBlob::Load/Store, and the guarantee written at the accessors themselves. The wire and the on-disk image are unchanged, so the one open finding whose fix was going to cost a format break turned out not to be one. -fno-sanitize=alignment is gone from linux-gcc-asan, which is the check that says so - and it went red on two gates this finding had never named before it went green, which is the argument for re-arming a check rather than trusting a row. Read that list as part of this file's posture, because it is.

Please do not open a public issue for a security problem. The regular issue tracker is public, and a report there discloses the flaw before there is a fix.

Use GitHub's private vulnerability reporting instead:

Repository → Security tab → Report a vulnerability

If GitHub private reporting is not available to you — or the button is not there — email:

info@ivyware.com.au

with SECURITY in the subject line. This is the same address the contact page publishes, and it is a general mailbox rather than a dedicated security one: say so in the subject or the first line, because that is what routes it. There is no PGP key. If you need to send something you would rather not put in cleartext mail, say so without the detail and you will be given somewhere to put it.

The same detail that makes a normal bug report actionable, plus the security specifics:

• What the flaw is, and what an attacker gains from it
• Reachability — pre-authentication or post-? Which transport (P2PeerConWsa, P2PeerConPipe, P2PeerCon232, P2PeerConDmx)?
• Affected file and line, against a named commit
• A reproducer if you have one — a crafted frame, a test harness, a crash dump
• Build identity — configuration and platform (Release|x64 etc.), toolset, Windows version
• For a crash: the call stack, and whether the pump thread or the caller's thread was on it

Concurrency and lifetime bugs dominate this codebase. A report that names which thread is worth ten that do not.

This is a small, unfunded project. These are honest targets, not a contractual SLA.

In scope — anything in this repository that an attacker can reach:

• The receive and framing path, on any transport
• Message routing, addressing, and handler dispatch
• The end-to-end seal and the identity/allow-list storage
• Memory-safety defects: overflow, use-after-free, type confusion, integer overflow
• Concurrency defects with a security consequence
• The flat C ABI (Targetcore_c.h and its _u8 twins) — 101 entry points exported from the DLL/.so, restored to this repository on 2026-08-14, and enumerated since 0.10.0 in .github/ci/abi-flat.manifest with two checks that keep the count honest. This said 74 until 2026-08-20 — the figure was accurate when it was written and the surface grew under it, which is exactly what the manifest now prevents. A scope statement that undercounts the surface excludes something by accident. Handle confusion, a handle the library never issued, a freed handle, and an exception escaping across the extern "C" boundary are all in scope here

Out of scope — already known and documented above; reporting these tells us nothing new:

• "There is no encryption on the wire" / "there is no peer authentication" on a hub that has opted out with RequireAuth(false) — that is a documented, deliberate posture, not a finding. This bullet used to say "a hub that has not been configured for either … the documented default posture", and since 2026-08-18 there is no such hub: an unconfigured hub does not start. A defect in the authentication or encryption path of a hub that arms very much is a finding
• "The DHKeyXChanger implementation is weak" (it has been deleted; findings against it are moot)
• The generated Java bindings in the separate Java tree — report those there. The C surface they are generated from is in this repository and is in scope, above
• Findings that require an already-compromised local machine
• Vulnerabilities in MFC, the Visual C++ runtime, the Windows SDK, OpenSSL, or liburing — report those upstream

We will work with you on a coordinated disclosure timeline and credit you in the fix commit and release notes unless you would rather stay anonymous. We will not take legal action against good-faith research conducted against your own systems and consistent with this policy.

If you are running Targetcore today, defence has to come from outside the library:

1. Bind to loopback where the peers share a machine; prefer P2PeerConPipe over P2PeerConWsa for local hub-to-hub links. Since 2026-08-27 P2PeerConWsa can do this itself — SetListenScope(P2PeerConScope_Loopback) on the SERVICE before it listens, and the socket binds 127.0.0.1 instead of INADDR_ANY. Until that release it bound every interface unconditionally and this advice could only be followed in a firewall. See 3d.
2. Put it inside a tunnel. A WireGuard or IPsec link, or an stunnel/TLS wrapper, gives you the confidentiality and peer authentication the library does not.
3. Firewall the listening port to an explicit allowlist of peer addresses. AllowAcceptFrom() (3d) now does a version of this inside the process; it does not replace the firewall, because a packet the firewall drops never costs this process a thread, a socket or a parse. 3a. Make the service's address domain as narrow as you can bear. For P2PeerConWsa the ServiceFactory peer argument is the accepted-address pattern, and it is the only thing restricting what a peer may claim to be. MyApp.Client admits exactly one identity; MyApp.* admits every peer to every identity under it, including each other's. Prefer one listening port per expected peer with an exact domain over one port with a wildcard, until the PSK work lands. 3b. Bound what an unconnected stranger can hold. Since 2026-08-16 a P2PeerCon in SERVICE mode takes SetMaxAccepted(n) — concurrent accepted connections, default 1024, 0 unbounds — and P2PeerConWsa takes SetBacklog(n). The default is generous, because it is a default; set it to what your deployment actually expects. Before that release there was no bound at all and the limit was the descriptor table. Guarded by p2p_acceptcap, on both platforms. Since 2026-08-19 it also takes SetMaxAcceptedPerSource(n) — the same bound per source IP, so one peer opening the whole cap and 1024 peers opening one each stop being the same thing to it. Off by default, because loopback and NAT both collapse many peers onto one address and a default that bound would refuse legitimate traffic silently at accept; set it if you know your topology. Guarded by p2p_srcbound. SetLoginDeadline(ms) drops a peer that connects and never logs in. It is off by default but safe to turn on, on either platform, since 2026-08-18 — the "it takes the listener down under Linux" warning that stood here was based on a cause that was traced and found wrong, and the real fault is fixed. Arm it anyway, and the reason has changed as of 2026-08-20. It used to be load-bearing: without it both accept bounds above counted connections ever accepted rather than currently held on Windows (F-S4-1), so the bounds did not release and the deadline was the only reaping path that worked on both platforms. F-S4-1 is fixed - an orderly close is now seen on Windows as it always was on Linux, gated by p2p_conreap - so the bounds release on their own and the deadline is no longer covering for a defect. What it still does is the thing it was always for: a peer that connects and simply never speaks holds a slot until it chooses to leave, and only a deadline takes that back. 3c. Watch the hub, and know what "quiet" means. Since 2026-08-19 P2PeerHub::Serialise() — the snapshot behind MSG_P2PexpHub and every P2Pevent carrying hub state — reports QueDepth (messages queued across all of the hub's pumps), Accepted (connections its services currently hold) and Throttled (backpressure holds applied). A monitor built on nothing but that call can alarm on all three; p2p_hubsnap is the gate that keeps it that way. Read QueDepth and Throttled together. Backpressure is on by default and holds a connection's reads at 37500 live messages, releasing at 25000, so a hub whose queue is low because it has stopped reading looks idle on QueDepth alone. A climbing Throttled with a low QueDepth is a hub holding the line, and it is the signal to add capacity — not a hub with nothing to do. SetP2PmsgBudgetMarks(high, low) lowers the marks if you want to feel it earlier.

3d. Say where you listen, and who may reach you. Two settings on P2PeerConWsa, added 2026-08-27, and they answer different questions — a deployment facing a network it does not own is expected to set both.

SetFamily(family) — WHICH ADDRESS SPACE, and it decides what the other two settings MEAN. P2PeerConFamily_IPv4 is the default and is what every caller written before 2026-08-28 keeps — this transport was AF_INET at all three socket sites until then, so a v6 peer could not reach a service at all. _IPv6 opens AF_INET6 with IPV6_V6ONLY on; _Dual opens it with the option off, one socket serving both families. The option is set explicitly in both directions and never inherited, because Windows defaults it on and most Linux distributions default it off: a socket that did not say would be v6-only on one build and dual-stack on the other from identical source, and a "v6-only" service that quietly admits v4 is the S9 failure this document keeps arguing about. Set it before Listen() on a service and before Connect() on a client. _Dual refuses a loopback scope rather than picking one — ::1 is not the v4-mapped form of 127.0.0.1, so no single bind covers both. Guarded by p2p_ipv6 and p2p_ipv6dual.

SetListenScope(scope, address) — the BIND. P2PeerConScope_Any is the default and is what every existing caller keeps. P2PeerConScope_Loopback binds 127.0.0.1 (or ::1 under _IPv6), and it is the only one of the two the kernel enforces: an off-host SYN is refused by the stack, so nothing in this library parses a byte of it. That matters more than it sounds, because everything before the login gate — the whole framing parser — runs on bytes with no provenance (THREAT_MODEL.md B1/B2). P2PeerConScope_Address binds one nominated local interface. An address this host does not hold makes bind() fail and drops the service rather than quietly widening to INADDR_ANY: a restriction that silently becomes no restriction is the S9 failure this document keeps arguing about. Set it before Listen(); a socket already listening keeps what it was bound to. Guarded by p2p_listenscope.

AllowAcceptFrom("192.168.1.0/24") — the ALLOW-LIST. A prefix list tested at accept against getpeername(), before the connection object is allocated and long before a login is attempted. AllowAcceptLoopback() and AllowAcceptPrivate() (RFC1918 + loopback + link-local, and their v6 counterparts ::1, fc00::/7 and fe80::/10) are the two shorthands most deployments want. Empty list = no restriction, which is the default. It answers false for a prefix it cannot parse and adds nothing — check the return, a rule that failed to parse is a filter narrower in your belief than in the socket. Guarded by p2p_acceptfilter.

Both families, and the trap in writing only one. A ':' in the rule makes it IPv6 ("2001:db8::/32", "fd00::/8", a bare "::1" meaning /128) and its absence IPv4, so a rule and its family cannot be written to disagree. A zone suffix is refused, because a rule that dropped it would be about every link rather than the one named — spell a link-local allow-list "fe80::/10". A rule matches only its own family, so a list holding only v4 prefixes refuses every v6 peer: on a _Dual service that is a restriction which will be believed to be about addresses and is really about which lines were written. The one place the two spaces touch is a v4 peer arriving on a dual socket as ::ffff:a.b.c.d, and this class normalises that back to AF_INET before it is tested — so "10.0.0.0/8" admits the same peer whichever socket carried it, which is not a convenience but the difference between one policy and two. Guarded by p2p_ipv6filter, which measures the normalisation through a real socket and not only through the decision.

The per-source bound counts a v6 peer by its /64. P2PsourceKey is 64 bits and a v6 address is 128, so something has to be lost and what is lost is chosen: the key is a hash of the /64 prefix, the block one host is routinely delegated. Keying the whole address would let a single subscriber line mint 2⁶⁴ keys and walk straight through SetMaxAcceptedPerSource. Two hosts in one /64 therefore share a share, deliberately. Bit 63 is set on every v6 key so it can never collide with a v4 one — and so ::1, whose /64 prefix is all zeroes, cannot fold to the 0 that means "the kernel would not name the origin".

Why both, and what neither buys you. A bind cannot express "the LAN": binding to a LAN interface's address restricts which interface accepts, not which source reaches it, so a packet forwarded in from the internet by a NAT or a port-forward arrives on that same interface and is accepted. And an allow-list is an address test, not a proof of locality — anything upstream that rewrites a source address can present a public peer under a private one. Neither is authentication. RequireAuth is still what decides who may speak; these decide who gets to be listened to at all.

The allow-list fails CLOSED, deliberately, and it is the opposite of SetMaxAcceptedPerSource sitting one line away in the same function. A source the kernel will not name is admitted by the per-source bound — an accounting bound that cannot identify its subject must refuse nobody, or one getpeername() failure stops the service — and refused by the allow-list, because an operator who wrote down who may connect has thereby said everybody else may not.

4. Run the process with least privilege. Handler code executes on the pump thread with whatever rights the host process holds, and there is no auth gate in front of it.
5. Keep handler maps minimal. Every ON_P2PeerMsg(...) entry is reachable by any peer that can complete a TCP connection. Do not register a handler you would not expose deliberately.
6. Treat P2PeerExplorer as sensitive. It reports live hub, pump, and connection topology and registers on an unverified source address.