Can we add support for running generic Ruby scripts?

[ioquatix]

https://github.com/rubygems/rubygems/blob/451ac56078a3deaacef640906070d3d8f7502570/lib/rubygems/ext/builder.rb#L122-L138

Can we add /\.rb/ or something that matches scripts ending in .rb and just run them with the Ruby interpreter? The current behaviour is inflexible.

[simi]

I have seen extconf.rb used to generate Makefile to just run custom script. Something like https://stackoverflow.com/a/38912965/319233.

What is your usecase @ioquatix?

[ioquatix]

I have two use cases.

• I want to use teapot to build external dependencies. https://github.com/kurocha/teapot
• I want to build libraries that use makefiles, but require autoconf to be executed before the build (to generate the makefile).

[ioquatix]

So, will you accept a script, e.g. /\.rb/ and executing it? It's almost no different from a rakefile except that we don't need to use rake.

[ioquatix]

I ran into this problem again. Any update?

[jchestershopify]

I am not a fan. Install scripts are a recurring cause of security issues, particularly credential harvesting.

[ioquatix]

Yes, but no different from extconf.rb so this proposed change does not change any risk.

[ioquatix]

@jchestershopify I agree with you, but according to the current interface, that is already possible. The only solution to that would be to use a sandbox for building native extensions. Which, I think is probably a good idea, but would be a totally separate issue.

Assuming that we just create a makefile which invokes a Ruby script, that's not practically different from what I'm proposing here, just that it's a simplification and it's more explicit. Otherwise, as @simi said, I can just use a hack to execute the code.

My use case is to use custom build tools, i.e. code which doesn't use any of the existing mechanisms. To be frank, the fact we have things like cmake or cargo built in directly, seems very specific to a particular use case, and I'm not sure why those were acceptable, but what about nix or npm or other tool chains... it seems like we are creating a pretty big maintenance burden.

[jchestershopify]

I know it's possible, but it's not widely known. I want to prevent further spreading of such a dangerous misfeature. Anything that adds awareness increases the number of attackers who are aware of this capability.

[ioquatix]

I don't think this matters for someone who is actively determined to attack something. If anything, this calls attention to how Ruby itself handles gems with native extensions - as any of them could already contain exploits. I don't think my proposed feature changes the security posture of Rubygems in any way since it's already trivially possible to do what you are suggesting (except that it's messy).

[simi]

@ioquatix what kind of build tools? cmake, make, cargo are used to build native extensions. Is it possible to build native extension using nix or npm? I would like to prevent easy way of coupling multiple package managers together.

[ioquatix]

Certainly there are more than just cmake, make and cargo in the world for building native extensions.

nix can build native packages, npm was just an example, I can imagine a Ruby package that wants to build npm assets at install time, but I don't have a strong opinion about it.

As you said, anything can be done by just making a custom makefile. But why make it so difficult?

Even make is not very useful, since a lot of packages require autoconf to run before running ./configure and make.

This seems like an arbitrarily specific "you must be this tall to go on the ride", and the arguments against making something more generic are all falling under "it's already possible to hack a makefile". But, I don't want to make a hack, I want to make something easy to maintain and understandable.

[rubyFeedback]

I actually agree with ioquatix on this. There is no logical reason I can think of why this should not be possible.

There is (at the least) one valid concern that needs to be handled, e. g. if is has a malicious goal, but this is a separate discussion and can be handled - it should not be used as rationale against this feature. So in short, I think ioquatix' request makes sense and should be implemented and documented.

ioquatix wrote:

Yes, but no different from extconf.rb so this proposed change does not change any risk.

Right, and as stated I agree with the request. One still has to be careful, even without a malicious case, people may do something accidental and end up with something they may not have wanted. As said this can be handled, but I think we also need to specify what to do, how to handle it, how it is documented. Perhaps it may help if you could e. g. show the full tasks done by the proposed use cases, and look through what could possibly go awry (or not); and then ideally have this also documented so people clearly see what is done and how. It is IMO better to think this through and have everything documented up-front; and as I said, I agree with the idea behind the proposal. We have to keep in mind that:

a) malicious use cases
b) accidental problems
c) people doing crazy things with it (though, that can not be prevented; but the use cases should be clearly documented for people to also read about it)

Edit: Another thing I was thinking ... does this create/delete files/directories? If so then we also should think about it, e. g. how people wanted to have reproducible builds.