3 ms·
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 internal
by jwilk 9y ago
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):
--- a/.git/config
+++ b/.git/config
@@ -0,0 +1,2 @@
+[core]
+ pager = cowsay
- schoen 9y ago______________________ < that looks dangerous > ---------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||
- Ajedi32 9y agoDid git write its own custom implementation of patch from scratch? Or does it use `patch` internally?
- jwilk 9y agoThey have their own implementation.
- tedunangst 9y agoAssuming 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.)
- jolmg 9y agoHuh. 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.