文件最后提交记录最后更新时间
fix(whatsapp): reject strangers by default, never respond in self-chat (#8389) (#21291) Self-chat mode (default) previously replied to ANY incoming DM with a Python-side pairing-code message. Two compounding defaults: 1. allowlist.js::matchesAllowedUser returned true for an empty allowlist — so WHATSAPP_ALLOWED_USERS unset → everyone passes the JS bridge gate → messages reach Python gateway → _is_user_authorized returns False but _get_unauthorized_dm_behavior falls back to 'pair' → stranger gets a pairing code reply. 2. bridge.js had no mode check on !fromMe messages, so self-chat mode (where the operator only wants to talk to themselves) forwarded everything anyway. Fix: - allowlist.js: empty allowlist now returns false. Operators who want an open bot must set WHATSAPP_ALLOWED_USERS=* explicitly (the existing wildcard behaviour, consistent with SIGNAL_GROUP_ALLOWED_USERS). - bridge.js: self-chat mode hard-rejects all !fromMe messages at the bridge, before they ever reach the Python gateway. Bot mode still enforces the allowlist. - Startup log message updated to reflect the new per-mode behaviour (was '⚠️ No WHATSAPP_ALLOWED_USERS set — all messages will be processed', which was both inaccurate post-fix and a bad default signal pre-fix). - allowlist.test.mjs: new regression test pinning the empty-rejects contract, + null/undefined defensive cases. Behaviour delta for existing users: - self-chat mode, no allowlist: strangers got pairing codes, now silently dropped. Strictly better. - bot mode, no allowlist: strangers got pairing codes via the Python-side pairing flow, now silently dropped at the JS bridge. Operators who genuinely want an open bot set WHATSAPP_ALLOWED_USERS=*.28 天前
fix(whatsapp): reject strangers by default, never respond in self-chat (#8389) (#21291) Self-chat mode (default) previously replied to ANY incoming DM with a Python-side pairing-code message. Two compounding defaults: 1. allowlist.js::matchesAllowedUser returned true for an empty allowlist — so WHATSAPP_ALLOWED_USERS unset → everyone passes the JS bridge gate → messages reach Python gateway → _is_user_authorized returns False but _get_unauthorized_dm_behavior falls back to 'pair' → stranger gets a pairing code reply. 2. bridge.js had no mode check on !fromMe messages, so self-chat mode (where the operator only wants to talk to themselves) forwarded everything anyway. Fix: - allowlist.js: empty allowlist now returns false. Operators who want an open bot must set WHATSAPP_ALLOWED_USERS=* explicitly (the existing wildcard behaviour, consistent with SIGNAL_GROUP_ALLOWED_USERS). - bridge.js: self-chat mode hard-rejects all !fromMe messages at the bridge, before they ever reach the Python gateway. Bot mode still enforces the allowlist. - Startup log message updated to reflect the new per-mode behaviour (was '⚠️ No WHATSAPP_ALLOWED_USERS set — all messages will be processed', which was both inaccurate post-fix and a bad default signal pre-fix). - allowlist.test.mjs: new regression test pinning the empty-rejects contract, + null/undefined defensive cases. Behaviour delta for existing users: - self-chat mode, no allowlist: strangers got pairing codes, now silently dropped. Strictly better. - bot mode, no allowlist: strangers got pairing codes via the Python-side pairing flow, now silently dropped at the JS bridge. Operators who genuinely want an open bot set WHATSAPP_ALLOWED_USERS=*.28 天前
fix(whatsapp): fail fast when Baileys sendMessage hangs Baileys' sock.sendMessage() can hang indefinitely while uploading media to WhatsApp servers (and, less often, on text sends), pinning the bridge's Express handler until the gateway's aiohttp timeout fires — surfacing to the user as a 120s wait followed by an empty error from the TTS/voice path. Wrap every sock.sendMessage() call inside the bridge in a sendWithTimeout() helper that rejects after WHATSAPP_SEND_TIMEOUT_MS (default 60s) via Promise.race. The four call sites are /send, /edit, and /send-media's primary send. Express handlers catch the rejection in their existing try/catch and return a real 500 to the gateway, which can then surface a retryable error. Salvaged from #2608 — wysie diagnosed the hang and the Promise.race shape; the other two parts of that PR (gateway HTTP session pooling, base.py metadata kwarg removal) already landed on main via separate routes and are no longer needed. Co-authored-by: Teknium <127238744+teknium1@users.noreply.github.com> 20 天前
chore(deps): bump protobufjs in /scripts/whatsapp-bridge (#28889) Bumps [protobufjs](https://github.com/protobufjs/protobuf.js) from 7.5.6 to 7.6.0. - [Release notes](https://github.com/protobufjs/protobuf.js/releases) - [Changelog](https://github.com/protobufjs/protobuf.js/blob/protobufjs-v7.6.0/CHANGELOG.md) - [Commits](https://github.com/protobufjs/protobuf.js/compare/protobufjs-v7.5.6...protobufjs-v7.6.0) --- updated-dependencies: - dependency-name: protobufjs dependency-version: 7.6.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>14 天前
fix(whatsapp): pin protobufjs >=7.5.5 via npm overrides to clear 3 critical vulns (#19204) The whatsapp-bridge pulls @whiskeysockets/baileys at a pinned git commit whose transitive dep tree ships protobufjs <7.5.5, triggering GHSA-xq3m-2v4x-88gg (critical, arbitrary code execution). npm audit reported 3 cascading criticals: protobufjs, @whiskeysockets/libsignal-node (pulls protobufjs), and baileys itself (effect rollup). Fix: add npm overrides block pinning protobufjs to ^7.5.5. Deduplicates to a single 7.5.6 copy at node_modules/protobufjs that both libsignal-node and any other consumers resolve through normal module resolution. Why not bump baileys: npm-published baileys@6.17.16 is deprecated by the maintainers (wrong version), 7.0.0-rc.* still pulls the same vulnerable libsignal-node, and upstream Baileys HEAD adds a 4th vuln (music-metadata). The override is the minimal, behavior-preserving fix. Validation: - npm audit: 3 critical -> 0 vulnerabilities - node -e "import('@whiskeysockets/baileys')" -> all 5 named exports (makeWASocket, useMultiFileAuthState, DisconnectReason, fetchLatestBaileysVersion, downloadMediaMessage) resolve - node bridge.js loads all modules and reaches Express bind (exits only on EADDRINUSE because the live gateway owns :3000) - Single deduped protobufjs@7.5.6 in the tree1 个月前