> The majority of uses of patch are applied to source code by someone who's going to end up running that code anyways, so applying patches you haven't read closely from sources you don't trust is already unsafe.
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.
If possible, you should use your VCS's native tool for applying patches, not patch(1). Otherwise, you risk that the patch will mess with the repository internals.
For example, this patch compromises git repositories when applied with patch(1):
Huh. I was going to say how git-apply(1) probably uses patch(1) internally after doing some preprocessing on the patches it's given, but, on checking it, it seems it doesn't.
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.
Assuming git patch doesn't simply exec patch. (It doesn't, but half the comments here are people saying they want all their tools to run all the other tools because unix.)
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.