Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

JSON-RPC: sendChatText / broadcastChatMessage / setServerName accept unbounded strings

Đang mở
  • Có gì không ổn?
#3,950 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

@ann0see đang làm issue này rồi.

Từ ngày 14/9/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

AI

Describe the bug

jamulusclient/sendChatText, jamulusserver/broadcastChatMessage and jamulusserver/setServerName validate only that their string parameter is a string — no length bound — unlike the sibling chat methods, which reject input above MAX_LEN_CHAT_TEXT (1600):

  • jamulusserver/privateChatMessage — rejects > MAX_LEN_CHAT_TEXT (src/serverrpc.cpp:125).
  • jamulusserver/setWelcomeMessage — rejects > MAX_LEN_CHAT_TEXT (src/serverrpc.cpp:325).

Normal clients cannot produce such input: the GUI chat dialog truncates input at MAX_LEN_CHAT_TEXT (src/chatdlg.cpp:111). So these three methods deviate from both the peer RPC methods and the GUI path.

Reachable impact on current main

Since #3861 the JSON-RPC transport caps each request line at 16 KiB (MAX_JSON_RPC_REQUEST_BYTES, src/rpcserver.cpp:116), so the message is transport-bounded. It still exceeds the receive-side limits: EvaluateChatTextMes reads at most MAX_LEN_CHAT_TEXT_PLUS_HTML (1800) chars (src/protocol.cpp:1424) and split reassembly caps at 36 parts, while the sender fragments via CreateAndSendMessage with ceil(len / 550) parts and no part-count cap (src/protocol.cpp:590). Result: a ~16 KiB broadcastChatMessage produces a ~27-datagram split burst per connected client that is then silently discarded by every peer. Not memory-unsafe; low severity, but the handlers do not enforce the parameter contract their siblings and the GUI do. An oversized setServerName similarly carries into server-list registration messages to directories and clients.

To Reproduce

  1. Run a server: jamulus -s --nogui --jsonrpcport 22150 --jsonrpcsecretfile <secret> (secret >= 16 chars), connect one client.
  2. Call jamulusserver/broadcastChatMessage with chatMessage of 10,000 chars. Handler returns ok; peers receive the fragmented message and drop it (receiver bound 1800).
  3. Call it with 20,000 chars: transport rejects with Parse error: Request exceeds maximum size of 16384 bytes.

Measured against 3.12.5dev (292506eb): 15,000-char broadcast accepted with a +416 KB server RSS delta and ~27 split parts per client; 20,000-char rejected by the 16 KiB boundary.

Expected behavior

sendChatText, broadcastChatMessage (and setServerName) reject input above MAX_LEN_CHAT_TEXT with iErrInvalidParams, mirroring privateChatMessage / setWelcomeMessage.

Version of Jamulus

3.12.5dev (292506eb), JSON-RPC enabled.

Additional context

Formalizes the "String parameters are bounded inconsistently" item of #3916. #3861 bounds the transport; this issue is the remaining handler-level gap.

🤖 Used AI: big-pickle, opencode

Ngôn ngữ chính
C
Star
1.1k
Fork
248
Merge trung bình
7 ngày 14 giờ
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jamulussoftware/jamulus

Tất cả issue của jamulussoftware/jamulus

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.