There are many inherent problems with utilities like file(1), however, if people are going to continue using them then we should try to make the best implementation possible.
This new implementation was created from scratch, carefully, with modern coding practices by a very proficient programmer.
I do think a cleaner, more careful file(1) implementation is a step in the right direction. But it's still a bit unnerving to me that a bug in a utility like file(1), which needs to do nothing but read a file and output text to stdout, could possibly do things like overwrite other files, write to the network, etc., even in the presence of parsing bugs and a maliciously crafted file. A parsing bug in a utility that does nothing but read files and parse them should not be able to do anything worse than force a misparse! The file(1) binary simply does not need to have permission to do things like write to the network or disk. This seems like a shortcoming of the traditional Unix permissions model. A promising direction imo is the more fine-grained permission model of Solaris/Illumos, which FreeBSD's Capsicum project also aims in the direction of.
While capability systems are totally awesome, for this sort of application, you don't really need it. Open the target file read-only, open the magic database read-only, keep stdout open, and then even something as restrictive as Linux's seccomp mode 1 sandbox (read(2), write(2), exit(2), nothing else) should be enough to let you print out an answer.
> This new implementation was created from scratch, carefully, with modern coding practices by a very proficient programmer.
Cool. What happens 10 years from now, when we've wanted all the missing features back, and when writing C code (let alone C code without tests) to run on untrusted input is no longer "modern coding practices" but firmly legacy?
This seems like a great way to have a version of file(1) that works great in 2015, on the subset of filetypes that are in-scope for the initial version, on this version of OpenBSD, but I'd like to know how it becomes sustainable.
Nobody is saying this is a perfect implementation, however, it has been written in-line with existing best coding practices that any OpenBSD developer should be comfortable with, and hence maintainable until it is deemed not to be. If everyone suddenly stopped depending on file(1), then it would happily be removed from the tree.
But it's sort of like living in a world where modern medicine has been discovered, and celebrating that one city has started moving away from leeching to treat fevers, while every other city is still practicing it, and that one city still uses leeching to treat many other diseases. Strictly speaking, it is an improvement, but....
That doesn't really seem like the right response to a culture of bloodletting, does it?
I was going for, let's quit bloodletting, but let's also not celebrate how we're occasionally no longer bloodletting, because it's still embarrassing how far behind modern medicine we are.
Bloodletting? That's just too crazy for words. The OpenBSD people produce first class code that's solves real problems in real production, and you compare it to witchcraft?
If you absolutely need speak in parables, do it with something that represents an earlier common practice, for example with producing houses with hammers and nails instead of modern pre-fab concrete blocks. But even that is stretching it a bit too far, the productivity difference simply isn't comparable.
Bloodletting isn't witchcraft. It removes iron from the body such that virii and bacteria trying to reproduce would have problems. It makes the host environment more hostile to the invading species. It has a lot of negative side effects and wasn't very effective, but it did have an effect.
Of course, some people did bloodlet for reasons that didn't help, but without knowledge of bacteria, many were just trying their best with what limited knowledge they did have.
Not him, but my interpretation is that we're writing C with little testing (treating a few fevers) conforming to modern standards over C with little testing conforming to old standards (leeching).
We have languages like Rust and we have proof tools like Coq which can be leveraged to become more memory safe or more provably correct... using those tools would be like using modern medicine.
I don't think the analogy is really that great because those tools are still incredibly immature in terms of actual usability.
This new implementation was created from scratch, carefully, with modern coding practices by a very proficient programmer.