←back to thread

1124 points CrankyBear | 4 comments | | HN request time: 0s | source
Show context
phkahler ◴[] No.45891830[source]
From TFA this was telling:

Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”

I agree with the headline here. If Google can pay someone to find bugs, they can pay someone to fix them. How many time have managers said "Don't come to me with problems, come with solutions"

replies(8): >>45891966 #>>45891973 #>>45893060 #>>45893320 #>>45896629 #>>45898338 #>>45902990 #>>45906281 #
dvfjsdhgfv ◴[] No.45893060[source]
> "Don't come to me with problems, come with solutions"

The problem is, the issue in the article is explicitly named as "CVE slop", so if the patch is of the same quality, it might require quite some work anyway.

replies(1): >>45893094 #
jeffbee ◴[] No.45893094[source]
The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1
replies(1): >>45893528 #
michaelt ◴[] No.45893528[source]
It's a good quality bug report.

But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1]

Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't been used since the Clinton administration. gstreamer divides their plugins into 'good', 'bad' and 'ugly' to give them somewhere to stash unmaintained codecs.

[1] https://web.archive.org/web/20250419105551/https://wiki.mult...

replies(5): >>45893611 #>>45893616 #>>45895592 #>>45895955 #>>45896300 #
1. rossjudson ◴[] No.45895955[source]
I'm sure that a hacker wouldn't think of trying to use an obscure format...

https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

replies(1): >>45896464 #
2. godelski ◴[] No.45896464[source]

  > If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it.
That's not an obscure format, that's an old format. Meanwhile with ffmpeg we're talking about

  > decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.
That's both old and obscure.

Your point is still taken, but just to clarify that these are different situations. JBIG2 is included for legacy. The Lucas art codec is included for... completion's sake(?)

replies(1): >>45901192 #
3. adgjlsfhk1 ◴[] No.45901192[source]
The problem is that if you have a process using ffmpeg and an attacker feeds it a video with this codec, ffmpeg will proceed to auto-detect the codec, attempt to decrypt and then then break everything.

If the format is old and obscure, and the implementation is broken, it shouldn't be on by default.

replies(1): >>45905098 #
4. godelski ◴[] No.45905098{3}[source]
Sorry, I probably wasn't clear enough in my comment. I was trying to say that being old gives some legitimacy for existing. Just because it is old doesn't mean it isn't used. Though yes, this should be better determined to make sure it isn't breaking workflows you don't know about.

But old AND obscure, well it's nice that it is supported but enabled by default? Fully with you there.