8 ms·

This is bad and should be fixed, but there are fairly few circumstances where it actually creates a new vulnerability. The majority of uses of patch are applied

This is bad and should be fixed, but there are fairly few circumstances where it actually creates a new vulnerability. 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.

simlevesque 9y ago
You could build the binary on your machine and run it inside a VM.
- zitterbewegung 9y ago
  To be honest qubes seems to become a better and better idea to run all of the time.
- petters 9y ago
  The patch could also modify the Makefile (or similar) to run arbitrary commands when the build is started.
archgoon 9y ago
The main place where this would be an issue would be if you have a server that is not going to build or run code, but applies patches to source and outputs the result. So a cr review website could be affected.
tzs 9y ago
> 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.
- 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 ago
    Did git write its own custom implementation of patch from scratch? Or does it use `patch` internally?
    - jwilk 9y ago
      They have their own implementation.
  - tedunangst 9y ago
    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.)
  - jolmg 9y ago
    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.
IshKebab 9y ago
Sure, except you could (for example) steal Linus's private ssh keys with this.
tomc1985 9y ago
That advice has been being passed around for a good long time, probably almost as long as patch itself.

simlevesque 9y ago

You could build the binary on your machine and run it inside a VM.

zitterbewegung 9y ago
To be honest qubes seems to become a better and better idea to run all of the time.
petters 9y ago
The patch could also modify the Makefile (or similar) to run arbitrary commands when the build is started.

archgoon 9y ago

The main place where this would be an issue would be if you have a server that is not going to build or run code, but applies patches to source and outputs the result. So a cr review website could be affected.

tzs 9y ago

> 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.

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 ago
  Did git write its own custom implementation of patch from scratch? Or does it use `patch` internally?
  - jwilk 9y ago
    They have their own implementation.
- tedunangst 9y ago
  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.)
- jolmg 9y ago
  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.

IshKebab 9y ago

Sure, except you could (for example) steal Linus's private ssh keys with this.

tomc1985 9y ago

That advice has been being passed around for a good long time, probably almost as long as patch itself.