Thank you for the quick response.
I had intended this as a medium-term fix to the referenced CVE that
Google found. In other words, SMUSH is specifically not secure. This
seems to be the most straightforward approach. It will prevent anyone
using auto-selection of the codec from being the victim of a malicious
payload while still allowing them to explicitly use SMUSH for
conversions if desired.
I had actually planned to add a new flag when I saw this mechanism
already existed for "experimental". I could add a new flag such as
"unsafe" or "pending_cve" or such and key off that as well in the same
place?
Or is it the position of ffmpeg that the SMUSH vulnerability should be
left in place until a full fix of the codec is made? Your @FFmpeg X
account made it sound like there would be no attempt to do this. But if
one is expected reasonably soon perhaps this is not a useful change anyway.
Best Regards,
Oliver
On 11/4/2025 5:56 PM, Rémi Denis-Courmont wrote:
Hi,
Experimental means part of an experiment. The SMUSH decoder might have
qualified as experimental while it was being implemented (reverse engineered?),
but not today.
What it is is unsupported, but the same could be said of, well, essentially
every codec in FFmpeg, as per the GPL/LGPL warranty disclaimer. SMUSH is also
not formally proven secure, but again, the same could be said of every codecs
(or almost) in FFmpeg as of today.
The same argument that FFmpeg should disable game codecs or other "unsupported"
was raised on Saturday at VDD. Though those discussions do not bind the FFmpeg project in
any way, most people in the room seemed to agree that classifying the hundreds of codecs
in such vague, variable and subjective wasn't viable.
In other words, it's up to whoever compiles the software downstream to
determine what they want to support and what they don't, IMO, not the FFmpeg
project/community.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
