haskellshill

Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?

> you have 90 days to fix it

Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here.

If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.

What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug.

> currently have zero real-world impact

So better we not talk about them until someone bothers to write an exploit for it?

> the "researchers" didn't even bother to write a patch/fix

If it has no real-world impact and thus shouldn't even be reported, then why does it need to be fixed?

There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?

Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.

>rarely anyone ever uses

It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

Yeah, I mean if it's an actual vulnerability what are they complaining for?

No :)

Again, you're focusing on a pointless detail. Sure, I made a mistake in offhandedly using li as an example. Why do you choose to ignore the actually valid p example though? Seems like you're more interested in demonstrating your knowledge of HTML parsing (great job, proud of ya) than anything else. Either way, you've given zero examples of benefits of not doing things the sensible way that most people would expect.

That's exactly my point, people are clueless about the basics of nuclear power. Why would they know it? I mean, why would the average person know what a linear equation is or what year the first world war started?

Well, just because something is allowed by the syntax does not mean it's a good idea, that's why pretty much every language has linters.

And I do think there's an evenly applied rule, namely: always explicitly close all non-void elements. There are only 14 void elements anyway, so it's not too much to expect readers to know them. In your own words "there's no substitute for actually knowing the real rules".

I mean, your approach requires memorizing for which 15 elements the closing tag can be omitted anyway (otherwise you'll mentally parse the document wrong (i.e. thinking a br tag needs to be closed is equally likely as thinking p tags can be nested)).

The risk that somebody might be expecting a closing tag for an hr element seems minuscule and is a small price to pay for conveniences such as (as I explained above) being able to find and replace a p tag or a li tag to a div tag.