# hexchat — 5-MOAD Scan CLEAN

## Target
HexChat IRC client — https://github.com/hexchat/hexchat

## Date
2026-03-31

## MOAD-0001 (CWE-407) — CLEAN
- `userlist.c`: user lookup uses a binary tree (`tree.c`) — O(log N) per lookup. No linear scan.
- `ignore.c`: `ignore_check()` scans `ignore_list` O(I) per message, where I = ignore entries.
  Called once per message. I is user-controlled and typically tiny (< 50). Not O(N²).
- `notify.c`: `notify_find()` scans `notify_list` O(N) per JOIN/QUIT. N = watch-list size,
  typically < 100. Called once per nick event. Not O(N²).
- No pattern found where a list membership test is nested inside an outer loop over
  the same or correlated collection.

## MOAD-0002 (Intertangle) — ACCEPTABLE
- Multiple global GSLists (`sess_list`, `ignore_list`, `notify_list`, etc.) in `hexchat.c`.
  This is the standard IRC client architecture — a single UI event loop with global state.
  Not a decoupling defect in our context; HexChat is not a server.

## MOAD-0003 (Leaked Context) — CLEAN
- HexChat is single-threaded (GLib main loop). No thread-local storage, no context leakage.

## MOAD-0004 (CWE-312) — CLEAN
- `tcp_send_real()` sends all outgoing data to `fe_add_rawlog()`, including
  `AUTHENTICATE <base64(nick\0nick\0pass)>` during SASL PLAIN login.
- `fe_add_rawlog()` writes only to an in-memory GTK widget (the Raw Log window).
  This window is NOT opened automatically and NOT written to disk.
- Session chat logging (`hex_irc_logging`) writes rendered channel text, not raw protocol.
- This is a debug diagnostic tool, not automatic credential exposure. LOW risk, not a defect.

## MOAD-0005 (Thundering Herd) — CLEAN
- Single-threaded event loop. No concurrent cache access patterns exist.
- `dcc.c` has a static host cache but it's single-threaded, no race possible.

## Verdict
All 5 MOADs: CLEAN (no patchable defects found).