RFC: Removing file(1)+libmagic(3) from the base system

[Colin Percival]

M. Warner Losh wrote:
> I would argue that it would make the system LESS secure, because one
> loses the ability to identify files on the system.  People are going
> to install it anyway, and it is a jump ball as to whether having it in
> the base system would cause vulnerabilities to be updated faster than
> having it in ports (both the actual update in the system, as well as
> the user causing the update to happen: ports are a touch easier to
> update, but lag a bit both in terms of people updating their ports
> tree and ports committers updating the port).

Interestingly, my experience from portsnap is that people tend to update
ports more frequently than they apply security patches to the base system.

> And for there to be any exploitable vulnerability, the attacker would
> need to feed the victum a bogusly formatted file, and cause the victum
> to run file on that file.  I doubt that the latest security hole will
> ever result in a system compromise...

You're more optimistic than I am, then.  This latest advisory was issued
on the basis of "it's a heap overflow in rather messy code, so we really
have no idea if it's exploitable".

> I guess I fail to see how this is any different than the .gz bugs that
> were found a while ago.  Nobody suggested removing .gz from the tree
> because a few bugs were found.  Everybody suggested updating right
> away to fix those bugs.  File is no different, and really should
> remain in the tree.

Deflate is one file format which is used quite often.  File parses several
different formats, including several which are not tested often (i.e., have
a much higher chance of including parse bugs).

Colin Percival