I realized what you meant after I posted that comment, so I deleted it (but obviously not before you replied). However we do disagree on the meaning of "exploit". If a file causes an application to crash, I consider that an exploit. It may not be arbitrary code execution, but it is exploitation of a denial of service vulnerability.
A denial-of-service vulnerability really ought to be something an attacker can force or plausibly trick you into doing, in such a way that you can actually be denied service. Calling "a file that, when opened, crashes the application" a vulnerability dilutes the term into uselessness. Even if someone somehow forces you to open the file, you don't lose VLC. You just lose this instance of VLC. You double-click on VLC again, and boom, up it comes, ready to go. That's an awfully low grade of "denial".
Just because you assume that VLC is going to be used as a desktop application and that exploitation would require opening a file by hand, doesn't mean that matches every use case.
VLC has broadcasting, relaying, stream processing capabilities, all scriptable. I have done POC transcoding and broadcast applications that required VLC. In these cases, a denial of service might be serious. Also, a use after free may involve other vulnerabilities that require more effort to exploit, but the onus is not on the reporter to iterate every possibility, it is on the developers to fix the bug.
This really sounds like an argument over triage of bugs for VLC (and perhaps some bad internal communications practices), and the VLC devs don't seem to understand that nobody cares about their internal process, just about getting the bugs fixed.
Don't get me wrong, I am not saying that is a good idea (I decided against it), but that the scope of this bug is much larger than just a desktop "Don't open that file then" kind of bug.
I'm not assuming anything. In fact my post has nothing to do with VLC, really. I'm challenging the idea that a crashing bug in a desktop app is a "denial of service". That's not a useful use of the term. If you want to talk about a different type of bug, go ahead... and you will be talking about a different kind of bug, so my comment won't apply to your new bug.
You completely missed the point. VLC is not just a desktop app. It's scriptable so it can be run on a headless server. Open Office is a desktop application but it's also a library that can be scripted against.
If I'm not really talking about VLC, how can I be missing the point?
I'm making the point I'm making. I have no obligation to be making the point you think I'm making, or you think I should make. You feel free to make others.
I don't really care if you call it a lie or not. I care that you attempted to invoke the legal system over a dispute regarding a vulnerability. I also care that you, by your own admission, lied.
Even if it were indisputably clear that Secunia did, in fact, knowingly lie about the vulnerability, I would still hold you in infinitely greater contempt for that sickening display of hypocrisy.
What would you do in VLC place? Ignore Secunia? Use the public megaphone and try to out-yell Secunia using twitter/media/blogs? Driver over to their HQ?
I total agree that invoking the legal system is a large step that shouldn't be invoked in vain, but I don't see many other options VLC team had here other than just ignoring Secunia.
A calm, thorough, carefully-proofread writeup free of legal threats and temper-tantrums sent to Secunia, and posted to FD, the VideoLAN development list, and the VideoLAN website, explaining VideoLAN's position. Direct future inquiries on the subject that don't proffer new information to that response.
Anything else is a gross overreaction to a garden-variety disagreement or misunderstanding.
I realized what you meant after I posted that comment, so I deleted it (but obviously not before you replied). However we do disagree on the meaning of "exploit". If a file causes an application to crash, I consider that an exploit. It may not be arbitrary code execution, but it is exploitation of a denial of service vulnerability.