Thou shalt have no other gods before the ANSI C standard 1618

I'm one of those a.f.c. posters, and have never suggested such a thing. Your point is exactly correct though, and should be part of the test plan. i.e. a good definition of "malicious". Presumably the coders of that format would know what needs to be done.

The real problem is poorly written code. What kind of processing the code does is not material. Complex processing of inputs simply means there may be more code to write. My own experience with things like AV streams reminds me a lot of any other protocol stream. It's just bits coming in. You don't write code that allows them to overflow buffers. It's simple.

That does not surprise me. When I used that paradigm, there would have been no reward for publishing something, and in fact doing so would have been a cost, or was not allowed.

Well written code (as has been pointed out many many times) will not suffer from the kind of attacks you suggest. AV code is no different than any other code. If you don't put the capability to overflow buffers into the code, then all attacks intended to exploit buffer overflow will simply fail. It's just not that hard to do.

And sometimes the "honeypot" solution is the best one.

--

... Hank