But the author is absolutely right, nowadays we should prefer red. Still a small amount of shame if you're applying untrusted patches.
I'm also reminded by a RMS writing (I think it was letter of some sort) campaigning that denying computer lab users root access was oppressive. Bit sad that I can't actually find it now.
And of course the classic (if misused like I'm doing here) Franklin quote "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
Put another way, it's easy to trust a user if you and they both know that they can be tracked down and face disciplinary action if their behavior was deemed unacceptable.
Having a culture of trust replaced by one of distrust.
There's a reference that may be related to this in the book "Hackers: Heroes of the Computer Revolution" that talks about how Stallman despised passwords and worked to promote more open access to the systems.
RMS has said multiple times that technology doesn't change our values, because our values are far too ingrained in order to be changed as something as trivial technology. But different technologies change the outcomes that we judge using our values. The proliferation of the internet and data sharing changes whether or not passwords are a good thing (since they are now used to protect user data from other people, rather than block users from accessing a system they should have the rights to access).
For posterity, this is bit more canonical source for the piece:
> Why GNU su does not support the `wheel' group
> (This section is by Richard Stallman.)
> Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)
> However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.
> I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.
because computing is now globally connected, not limited to small computer labs
That said, I'm all for preventing remote attacks; it's when people start thinking about locking the actual user out of the computer he/she owns that makes me offended.
Also I don't think his PC is "offline," but rather he does weird things like reading web pages via a script that scrapes the text and emails it to him.
I can pull up the email if you like. He's a pretty reasonable guy if you ask him a question, and is surprisingly responsive.
"[When] passwords first appeared at the MIT AI Lab I [decided] to follow my belief that there should be no passwords," Stallman would later say. "Because I don't believe that it's really desirable to have security on a computer, I shouldn't be willing to help uphold the security regime.""
I highly dought that. Most users use Windows and don't even have Anti-Virus/Firewall installed on there computers. Networking hardware is set to defualts. I would argue more computers and servers are unprotected because we have more computers and users online.
So that's how you end up with m4 being Turing-complete, being able to put shell commands in anything, that sort of thing.
You should still want your tools to have this power.
It's amazing what you can do with tools built like this and how _easy_ it is. People use the same motivation for making microservices, "do one thing well", they just don't think about it for command line utilities and treat shell scripting like a second class citizen.
Patch does a good job of patching. There is no reason why it should also have the job of being able to run arbitrary scripts.
FWIW, perl was what convinced me that the previous Unix-y ideal of "do one thing well", was overhyped.
That philosophy could also be applied recursively; Perl should do just one thing; it should be a good scripting language. The Perl JSON module should just do one thing; it should be a good JSON encoder and decoder. That doesn't mean it should be simple; the JSON module should have as much complexity as necessary to make it a good and useful tool.
I do recognize that my interpretation isn't a great _definition_, because you can construe most things to be UNIX-y if you just expand what "one thing" it should be good at enough, but I do think it's useful to keep in mind when designing something.
That said, I have never written Perl (other than a very tiny amount of Perl 6), and don't know exactly what about it convinced you, but I wouldn't mind a discussion about it if you clarify.
The main idea behind the "do one thing" is really composability: by doing one thing, your program can be used to provide the functionality for other programs to form applications. Patch uses ed because it needs to edit text and ed provides the text editing functionality, but ed can also be used interactively or from a shell script or by some other program. This is because ed doesn't care how it is called nor where the commands come from. This isn't enabled by its simplicity, but by its design to be composable: it would be a trivial difference in terms of complexity (and indeed there were similar programs in other systems that did exactly that) to ask the user for a filename upon launching it. But that would only make it useful as an interactive program (which is also why the Unix philosophy warns against captive user interfaces).
Ironically, Microsoft's COM and OLE followed that idea better than anything on the graphical side of Unix ever did (except X11 itself, but few programs ever took advantage of it - the best case would be applications meant to be "swallowed" inside docks - docklets - and panels, but those are very task specific). However there is also something to be said about being simple and COM is anything but simple.
>the power means the tool ends up doing a lot of other things ... not so well.
What I find myself wanting over and over is to do things with software that the developers didn't intend. Maybe using a hammer to mash potatoes is a bad idea, but I don't want the hammer company to make it impossible. Not because I want to shoot myself in the foot, but because preventing me from shooting myself in the foot prevents me from doing a lot of other good things.
It (patch) is not 'run[ning] arbitrary scripts' (ignoring the fact that the actual 'diff' output file is itself a 'script' in a broad sense).
Early versions of diff used to output 'ed' command scripts that would instruct 'ed' how to change one file into another file.
Rather than re-implement all of 'ed' inside of patch, patch simply was written to call 'ed' over a pipe and feed it the input "diff" (in 'ed' format) and let 'ed' handle interpreting the 'ed' script. This in and of itself makes sense. All the 'ed' code for interpreting 'ed' scripts is in 'ed', and enhancements to 'ed' automatically become available to patch and anyone else that calls 'ed' without having to keep plural code bases synchronized. Note that some of this usage may very well have been developed before shared libraries appeared, so there would have been no easy way to share the same 'ed' library among plural tools when there were no shared libraries.
It just so happens that one of ed's commands is a command to execute an arbitrary program. So a carefully crafted diff file can instruct ed to run a program of your choosing.
But I don't know if this is totally anti-unix; there's something more subtle, unix systems try to have a "proper layering" of tools, starting with high-level stuff like compilers and languages, sitting atop utility programs and shell, which ultimately sit on an OS kernel that offers its own similar layering of complexity, with simple and clean primitives at the very bottom (files, sockets, etc).
Working within this ecosystem of OS/libs/tools, you can compose any particular solution in a wide variety of ways, there's usually more than one "right way" to solve a problem. But the pieces you build your solution upon are generally more and more specialized/single-purpose as you move down the stack.
In case anyone has not been exposed to the reference, it's perhaps invoking the famous `ed, man !man ed` page.
I think you are overlooking a case that I suspect is common: applying a patch without reading the patch source and then using your source code control system to review what the patch did.
That lets you review that patch using whatever tools you normally use for reviewing code changes, which are often much nicer than reading a raw ed script.
For example, this patch compromises git repositories when applied with patch(1):
@@ -0,0 +1,2 @@
+ pager = cowsay
Using strings(1) on the git executable turns up "%s/patch", which made me suspect the executable path was interpolated, but `git diff ...@~ | strace -fe trace=execve git apply` on an arbitrary repo turned up nothing, and I couldn't find "%s/patch" in git's source.
< that looks dangerous >
So a cr review website could be affected.
sh: 1: ed: not found
patch: ed FAILED
patch works just fine for me, though, so ed is not required.
For patch to work correctly you have to allow executing ed commands (internally or by spawning ed) but for security reasons you better not let ed execute yet another program.
(I don't think I've ever used a system that didn't have ed installed by default.)
Which is sad because technically POSIX wants ed installed so purely technically, those distros aren't fully POSIX compliant.
It is available in the packages, of course.
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
... was Mail just the example at the time? and this is basically just the a generic reference to feature/scope creep?... I just don't get the highly specific inclusion of "Reading mail" as something that all programs expand towards.
The choice of this particular feature was not accidental. JWZ was a developer of Netscape Mail:
Most terminal mode IRC clients will at least tell you when you have new (locally-delivered) mail, for example.
Amazing how an ancient vuln can still be found hidden in plain sight.
We put a lot of effort into the test suite which makes it easy for others to test various experimental security checkers. This has been detailed in the "third party testing" section at: http://www.pixelbeat.org/docs/coreutils-testing.html
I recently did a lot of work using AFL-fast (poking mostly Perl & Lua and crappy IoT products). My experience is that AFL-fast yielded far better results (in a fraction of the time) when compared to AFL.
We've had a quick look at using oss-fuzz, which will need a bit of work since it's more suited to libraries rather than standalone utils.
Looks like at least _some_ GNU tools are covered: https://github.com/google/oss-fuzz/tree/master/projects/gnut...
Having said that, a lot of the core command line tools (not just the GNU coreutils) that are run against untrusted input could certainly be improved. I'd prefer the OpenBSD method though - if it can't exec then I don't need to worry about the bugs the auditor/fuzzer didn't find.
And that’s 2.5.4, 1.0.0 could have been released in 1985 for all we know.
I guess we have many eyeballs, yet not enough still :)
According to this, context diffs are not sent to ed.
Is the author suggesting that patch can be fooled to interpret a context diff as an ed diff?
Theres a file called pch.c with an excessive amount of parsing and "intuit" functions like intuit_diff_type().
patch has anthromorphised progress and error messages and tries to "guess".
However I am only a dumb end user. I should not question what I do not understand. Its all safe I'm sure.
If you blindly apply patches, you will be in risk as soon as you run or try to compile the patched command. This attack is just a bit faster because it happens as soon as you apply the patch.
For example, dpkg-source applies patches when you unpack source package. I don't think anybody expects code execution when unpacking stuff, even when this stuff is untrusted.
$ cat >a.out
I was expecting this post to go through the roof and was rather surprised it gained zero traction, lol. Nobody using the GNU toolchain anymore on HN or it just got drowned out idk ... https://news.ycombinator.com/item?id=16766577