bug#22838: New 'Binary file' detection considered harmful

[Paul Eggert]

On 02/29/2016 09:14 AM, Marcello Perathoner wrote:
> Keeping the old bug is far wiser than to fix it and introduce a new bug.

That depends on the bugs in question. The old bugs were pretty bad.

> Copying faulty input to the output is a preferable failure mode

Again, we cannot satisfy everybody. There are reasonable complaints from 
users if 'grep' blasts improperly-encoded data to their terminals, or 
more generally if grep's improperly-encoded output trashes other 
programs that read the output.  This is why grep has the -a option.  It 
sounds like you need grep's -a option for your application, and it 
should be easy to use -a.  It's not clear that -a should be the default.

> any process that feeds tainted (user-provided) strings to grep can now 
> be made to fail. Eg. a process that greps apache logs for known 
> exploit signatures will now fail if the attacker sends a bogus 
> user-agent string.

Such a process won't fail if it uses grep's -a option, or if it treats 
the "Binary file matches" diagnostic as an indication that there are 
possible attacks, or if it is run in a unibyte locale where all bytes 
are valid characters, or if it looks at grep's exit status. Granted, 
slapdash approaches that don't do any of these things will be 
vulnerable, but they'll be vulnerable even with older grep versions.