4 ms·

The commit message is: New implementation of the file(1) utility. This is a simplified, modernised version with a nearly complete magic(5) parser

The commit message is: New implementation of the file(1) utility. This is a simplified, modernised version with a nearly complete magic(5) parser but omits some of the complex builtin tests (notably ELF) and has a reduced set of options. ok deraadt What is significance beyond the obvious? What options are now missing? What are the tradeoffs? Beyond a simplified API, are there new capabilities, functionality/use-cases, and/or improved performance?

ploxiln 12y ago
brynet, who posted below, tweeted a pdf-rendered man page for the new openbsd file command: http://brynet.biz.tm/pub/file.1.pdf http://brynet.biz.tm/pub/file.1.pdf It seems to have all the options I'd ever use. In fact I've never used any options to file (though I do use it to quickly identify a handful of files, often enough). The only reason OpenBSD does this kind of thing is because they got annoyed with the vulnerabilities in the classic file/libmagic source which everyone seems to use. They probably disliked the code style / organization of the source enough that they didn't want to patch it up (which they also do fairly often for various ports). That said I've never personally looked at the source.
- brynet 12y ago
  > That said I've never personally looked at the source. I'd say very few people do, which is kind of scary for a utility like file(1), which people feed any random file without giving second thought.
elchief 12y ago
Seeing as it's OpenBSD it's probably much safer than existing versions
- prodigal_erik 12y ago
  There's only so much safety we should ever expect from code written in C by a human being.
  - jude- 12y ago
    The seL4 microkernel was written by hand, in C by fallible humans [1]. However, the authors were careful to do so in such a way that it was feasible to subsequently prove its equivalence to a Haskell program that was proven consistent with the seL4 specifications. My point is, the degree to which you can expect "safety" from a program (whatever that word means to you) is predicated on the degree to which you can trust the competence and practices of the developers, and the degree to which your definition of "safety" applies to the program's specifications. Remember, all programming languages are Turing-complete, which means you can blow your foot off with any of them if you're not careful. [1] http://www.nicta.com.au/pub-download/full/7371 http://www.nicta.com.au/pub-download/full/7371
    - prodigal_erik 12y ago
      That's sort of what I was thinking of. I wouldn't say seL4 was written by hand, more cross-compiled in a way they couldn't fully automate, only because they didn't have a Haskell code generator that optimizes well when you don't need laziness or GC.
brynet 12y ago
The current de facto file(1) implementation was originally written in the 1980's, which was a very different time. It has been continually maintained since then, but it was still holding onto a lot of legacy idioms that have lead to some pretty significant security vulnerabilities in recent times. This is a simple implementation that includes a safer new magic(5) parser and excludes many of the "built-in" parsers that the contemporary file had, i.e: for executable formats, which are probably better examined with specially tools like objdump(1). The original author shared this very fitting sentiment on the news the new file(1)... http://marc.info/?l=openbsd-cvs&m=142989483913635&w=2 http://marc.info/?l=openbsd-cvs&m=142989483913635&w=2 "The Albatross fell off, and sank Like lead into the sea." — Ian Darwin The Rime of the Ancient Mariner

ploxiln 12y ago

brynet, who posted below, tweeted a pdf-rendered man page for the new openbsd file command: http://brynet.biz.tm/pub/file.1.pdf http://brynet.biz.tm/pub/file.1.pdf It seems to have all the options I'd ever use. In fact I've never used any options to file (though I do use it to quickly identify a handful of files, often enough). The only reason OpenBSD does this kind of thing is because they got annoyed with the vulnerabilities in the classic file/libmagic source which everyone seems to use. They probably disliked the code style / organization of the source enough that they didn't want to patch it up (which they also do fairly often for various ports). That said I've never personally looked at the source.

brynet 12y ago
> That said I've never personally looked at the source. I'd say very few people do, which is kind of scary for a utility like file(1), which people feed any random file without giving second thought.

elchief 12y ago

Seeing as it's OpenBSD it's probably much safer than existing versions

prodigal_erik 12y ago
There's only so much safety we should ever expect from code written in C by a human being.
- jude- 12y ago
  The seL4 microkernel was written by hand, in C by fallible humans [1]. However, the authors were careful to do so in such a way that it was feasible to subsequently prove its equivalence to a Haskell program that was proven consistent with the seL4 specifications. My point is, the degree to which you can expect "safety" from a program (whatever that word means to you) is predicated on the degree to which you can trust the competence and practices of the developers, and the degree to which your definition of "safety" applies to the program's specifications. Remember, all programming languages are Turing-complete, which means you can blow your foot off with any of them if you're not careful. [1] http://www.nicta.com.au/pub-download/full/7371 http://www.nicta.com.au/pub-download/full/7371
  - prodigal_erik 12y ago
    That's sort of what I was thinking of. I wouldn't say seL4 was written by hand, more cross-compiled in a way they couldn't fully automate, only because they didn't have a Haskell code generator that optimizes well when you don't need laziness or GC.

brynet 12y ago

The current de facto file(1) implementation was originally written in the 1980's, which was a very different time. It has been continually maintained since then, but it was still holding onto a lot of legacy idioms that have lead to some pretty significant security vulnerabilities in recent times. This is a simple implementation that includes a safer new magic(5) parser and excludes many of the "built-in" parsers that the contemporary file had, i.e: for executable formats, which are probably better examined with specially tools like objdump(1). The original author shared this very fitting sentiment on the news the new file(1)... http://marc.info/?l=openbsd-cvs&m=142989483913635&w=2 http://marc.info/?l=openbsd-cvs&m=142989483913635&w=2 "The Albatross fell off, and sank Like lead into the sea." — Ian Darwin The Rime of the Ancient Mariner