Can we add support for running generic Ruby scripts?

[ioquatix]

rubygems/lib/rubygems/ext/builder.rb

Lines 122 to 138 in 451ac56

	def builder_for(extension) # :nodoc:
	case extension
	when /extconf/ then
	Gem::Ext::ExtConfBuilder
	when /configure/ then
	Gem::Ext::ConfigureBuilder
	when /rakefile/i, /mkrf_conf/i then
	@ran_rake = true
	Gem::Ext::RakeBuilder
	when /CMakeLists.txt/ then
	Gem::Ext::CmakeBuilder
	when /Cargo.toml/ then
	Gem::Ext::CargoBuilder.new
	else
	build_error("No builder for extension '#{extension}'")
	end
	end

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]

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