Matthew Winn wrote:
If there was a security problem in Vim do you really think it couldn't be exploited in 100 characters? That's a pretty shaky foundation on which to build your security.
I am quite surprised at the lack of appreciation for the merits of "defense in depth" here. I am not claiming that a length limit would preclude damage, just that a modeline should be sanity checked before execution, and a reasonable length would be the first check. It's certainly true that a modeline of 100 bytes could wreak havoc on an unpatched Vim. But it is quite possible that a future vulnerability might allow code to be injected from a modeline, and limiting its length *might* make the attacker's job harder. It's sensational that Vim can process files with very long lines, for the occasions we need that. But it would be absurd for Vim to process a multi-megabyte modeline. By all means abuse me for my cheeky suggestion to limit modelines to 100 bytes, but while doing that you might agree that some limit under 1MB should be enforced.
A web browser should be able to handle anything thrown at it in a way that doesn't compromise security. _Every_ application should be able to handle anything thrown at it in a way that doesn't compromise security.
Even if a program is perfect now, a later change can introduce a bug. Any program which can automatically execute untrusted code should sanity-check the input as a separate step from sandboxing. That is standard Security 101 stuff - not my idea.
What you're suggesting isn't much different from security through obscurity.
Jargon is great, but not when it's misused.
Perl and Vim have exactly the same requirements: the need to safely handle code taken from an untrustworthy source. It makes no difference whether it comes directly from a network or from a disk. (If, like me, you use Vim as your source viewer for web pages, the need for the same level of security is obvious.)
It doesn't matter, but for the record, Perl's tainting system is not related to the scenario you describe. Perl wants to make sure that untrusted input is not later used as the basis for some expression that could do harm, such as executing SQL code. John
