Subj : src/sbbs3/main.cpp sbbs.h termaudio.c termaudio.h termaudio_cache.cpp
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Thu Sep 24 2026 21:22:49

https://gitlab.synchro.net/main/sbbs/-/commit/5b9f0f0bd4434aabd0872e33
Modified Files:
	src/sbbs3/main.cpp sbbs.h termaudio.c termaudio.h termaudio_cache.cpp termaudio_test.c
Log Message:
termaudio: trust a cached sound only if its contents match its name

Message text can write into a reader's SyncTERM file cache: putmsg()
strips the C;L query but passes the C;S store command through. A post
could therefore store its own file under the content-addressed name of
one of the system's sounds, and later sessions, seeing that name in the
C;L listing, would play it instead of uploading the real one. An entry
is now accepted only when the MD5 the client reports for the file
matches the hash in its name, so a planted file is treated as absent and
overwritten by the next upload. A file planted during the current
session can still be played until that session ends.

Also:

Keys typed while waiting for the C;L reply were discarded, and a reply
too large for the buffer was abandoned partway, leaving its remainder to
be read as keystrokes. The reply is now scanned by a separate, unit-
tested function: bytes before the reply are handed back to the input
stream in order, and an oversized reply is read to its end and used up
to what fit. Lines the truncation cuts short fail the MD5 check.

Only letters and digits are taken from a file's extension when building
its cache name, which is sent inside an APC. A ';' there split the
command's fields, and an ESC could end the string.

The cache name of each file is remembered for the session, keyed on
size and modification time, so replaying a large preloaded file no
longer reads and hashes all of it again just to find it already cached.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.