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

binstubs of removed gems stick around #2152

Closed
jjb opened this Issue Nov 9, 2012 · 9 comments

Comments

Projects
None yet
3 participants
@jjb
Contributor

jjb commented Nov 9, 2012

the behavior i see with 1.2.1: once a binstub is installed, it's there forever. removing the gem doesn't remove it, and running bundle install --binstubs only adds new ones, doesn't delete unused ones.

is this the behavior that is expected?

at the very least, it would be nice if bundle install --binstubs removed old binstubs. i suppose it doesn't because maybe there are arbitrary other things in the /bin directory unrelated to bundler and you don't want to mess with it.

it would be nice if things were automagically managed throughout. after setting a config flag, installing and uninstalling gems automatically added and removed binstubs.

what do you think of this feature? would you be interested in an experimental PL?

@indirect

This comment has been minimized.

Member

indirect commented Nov 9, 2012

Yeah, that is the expected behaviour. As you noted, we don't delete things just in case there is something in there that you do want. One way to "update" your binstubs is to just rm -rf bin before you bundle install. A pull that cleans the binstubs dir as part of the prune command might be nice, though.

On Nov 8, 2012, at 6:58 PM, John Joseph Bachir notifications@github.com wrote:

the behavior i see with 1.2.1: once a binstub is installed, it's there forever. removing the gem doesn't remove it, and running bundle install --binstubs only adds new ones, doesn't delete unused ones.

is this the behavior that is expected?

at the very least, it would be nice if bundle install --binstubs removed old binstubs. i suppose it doesn't because maybe there are arbitrary other things in the /bin directory unrelated to bundler and you don't want to mess with it.

it would be nice if things were automagically managed throughout. after setting a config flag, installing and uninstalling gems automatically added and removed binstubs.

what do you think of this feature? would you be interested in an experimental PL?


Reply to this email directly or view it on GitHub.

@jjb

This comment has been minimized.

Contributor

jjb commented Nov 9, 2012

or there could be a specially-name directory (bundler-bin)

@jjb

This comment has been minimized.

@indirect

This comment has been minimized.

Member

indirect commented Nov 9, 2012

You can already do that, by running bundle install --binstubs=bundler-bin

On Nov 8, 2012, at 7:58 PM, John Joseph Bachir notifications@github.com wrote:

or there could be a specially-name directory (bundler-bin)


Reply to this email directly or view it on GitHub.

@indirect

This comment has been minimized.

Member

indirect commented Nov 9, 2012

My plan to eliminate bundle exec is actually pretty similar to that post -- a Bundler-specific systemwide bin directory, and rvm or rbenv can add it to the path.

On Nov 8, 2012, at 8:09 PM, John Joseph Bachir notifications@github.com wrote:

(reason I'm thinking about this: http://code.jjb.cc/2012/11/09/putting-your-rbenv-managed-bundler-specified-executables-in-your-path-more-securely/ )


Reply to this email directly or view it on GitHub.

@jjb

This comment has been minimized.

Contributor

jjb commented Nov 9, 2012

You can already do that, by running bundle install --binstubs=bundler-bin

Right -- but if bundler uses a special dir from default or it's specified in config, then bundler could confidently blow away its entire contents (or otherwise arbitrarily manage it) when removing gems with executables and/or running install --binstubs.

@indirect

This comment has been minimized.

Member

indirect commented Nov 9, 2012

I guess it's arguable that Bundler could already delete every file in the binstubs dir, since users have to opt in to binstubs already. That said, why not just read the first 2k of each file in the binstubs dir to see if it's a Bundler stub?

On Nov 8, 2012, at 8:52 PM, John Joseph Bachir notifications@github.com wrote:

You can already do that, by running bundle install --binstubs=bundler-bin

Right -- but if bundler uses a special dir from default or it's specified in config, then bundler could confidently blow away its entire contents (or otherwise arbitrarily manage it) when removing gems with executables and/or running install --binstubs.


Reply to this email directly or view it on GitHub.

@jjb

This comment has been minimized.

Contributor

jjb commented Nov 9, 2012

okay, could do that too :D

@xaviershay

This comment has been minimized.

Contributor

xaviershay commented Aug 18, 2013

That said, why not just read the first 2k of each file in the binstubs dir to see if it's a Bundler stub?

Because that's a terrible hack :)

Feels like their might be a feature in here, if anyone wants to provide a patch or add something to bundler features, go right ahead. Closing because I don't consider it a bug.

There is still a security risk when downloading projects with Gemfile present, but now it’s much smaller. An alternative would be to check for .my_special_file instead of Gemfile — that file would have to have a non-standard name in order to be fully secure. Eventually I want to switch to this even more secure method, but I can’t think of an elegant way to pick its name, so I’m sticking with Gemfile :-D. (From the blog post)

This is unacceptable. Many people post their dotfiles online, conditionally adding ./bin to the PATH is still a security risk.

@xaviershay xaviershay closed this Aug 18, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment