Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem when /bin/sh doesn't exist #80

Open
Neo-Oli opened this issue May 5, 2017 · 4 comments
Open

Problem when /bin/sh doesn't exist #80

Neo-Oli opened this issue May 5, 2017 · 4 comments
Milestone

Comments

@Neo-Oli
Copy link

Neo-Oli commented May 5, 2017

I'm trying to get this to run on Termux. /bin/sh doesn't exist on this system. I had to change Line 361 to let s:shell = 'sh' to get it to work. Perhaps this should be the default, or at least be a fallback if /bin/sh doesn't exist

@jamessan
Copy link
Owner

jamessan commented May 6, 2017

Thanks for the report! That sounds like a reasonable change.

@jamessan
Copy link
Owner

jamessan commented Jun 1, 2017

@Neo-Oli Hmm, it's fairly common to hard-code well known paths like /bin/sh, especially when you want to reduce the chances of running arbitrary executables. Is Termux really expecting all software that gets run in that environment to have to change? There are over 200,000 matches for /bin/sh on Debian's code search.

@Neo-Oli
Copy link
Author

Neo-Oli commented Jun 1, 2017

@jamessan Those 200'000 matches are mostly shebangs, which can be easily dealt with (termux-fix-shebang in Termux). The problem is when /bin/sh or similar gets executed directly from the script. Also this is not a Problem of Termux. It's a problem of Android. Android doesn't have a /bin/ directory (It has /system/bin/). So code like this can't run on Android. But it's not just Termux that this problem occurs on. All Prefixed systems, like Gentoo Prefix, likely suffer from the same problem. That's why most modern software tries to avoid hard-coding paths.
Checking if /bin/sh is executable is a good idea anyway, since the error messages it gives lead one to conclude that gpg is somehow broken. I implore you to at least use the sh that's in the $PATH if /bin/sh is not executable.

@jamessan
Copy link
Owner

jamessan commented Jun 2, 2017

That's why most modern software tries to avoid hard-coding paths.

I get that, but there are trade-offs to that choice. Allowing any arbitrary executable in $PATH which happens to be named sh to run increases the potential risk of exposing the user's sensitive information. Although, I guess that argument doesn't really hold water given that the plugin is not using a qualified path for gpg itself.

Checking if /bin/sh is executable is a good idea anyway, since the error messages it gives lead one to conclude that gpg is somehow broken.

Completely agree with this point.

@jamessan jamessan added this to the todo milestone May 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants