SoylentNews is people
SoylentNews
from the not-your-daddy's-unix-anymore dept.
Via BSD Now, the old, familiar file command has been completely rewritten by OpenBSD developer Nicholas Marriott, who also happens to be the author of tmux. This new edition takes advantage of modern coding practices and the usual OpenBSD scrutiny. It will run by default as an unprivileged user with no shell, and in a systrace sandbox, strictly limiting what system calls can be made and has a drastically reduced potential for damage which a malicious file could do. Ian Darwin, the original author of the utility, saw the commit and, in what may be a moment in BSD history to remember, replied.
The file utility has been around since the 1970s and is used to determine what type of file something actually is. It hasn't seen a lot of development these days, and it's had its share of security issues as well. Some of those security issues remained unfixed, despite being publicly known for a while. It is run to inspect all kinds of files and was technically designed to be used on untrusted files, so tightening things up improves the situation quite a bit.
(Score: 5, Interesting) by NCommander on Thursday April 30 2015, @08:57AM
Oh god, C is ugly enough, K&R C, the very few times I've run into it, make me want to stab my bloody eyes out. This reminds me of my last major coding project before departing my last employer. I was dealing with early boot initialization code that theoretically should have been platform agnostic, but needed to know the stack starting point, and other bits of memory of the memory map. The information was available as part of a massive file blob known as a flattened device tree. No one could agree on anything. I looked at the problem and deduced the following:
1. The current specifications didn't allow passing the memory map, or even a scratch memory space, but did allow deducing a RAM or ROM offset of the FDT
2. The file format involved strings, multiple layers of lookup tables, and other "fun stuff". Added points for packing the whole thing big endian due to its PowerPC heritage (this platform was little endian)
3. I had 2048 bytes of storage available in processor registers
I could understand why it was considered impossible, but I also realized a couple of things
1. Given my codebase had to sit in a single page, and I could use the PC to figure out my base address, I could MAKE a stack out of a couple of registers holding offsets (if you're familiar with real mode X86, think near pointers)
2. I technically had more memory and processing power just counting the register storage than the original NES.
3. GOTO is a perfectly programming methodology if you've got nothing else, and you comment. Heavily.
The end result was approximately 900 instructions, 2000+ lines of commenting to explain it, and did the impossible. I remember one of my co-workers looked at it and basically went "WTF". Unfortunately, due to the same politics I suspect, it appears to have never been used.
Still always moving