"but the ecosystem is the biggest problem by promoting magic."
This argument isn't entirely true anymore. The Ruby ecosystem has mostly moved away from meta-programming, and embraced classical OOP. Rubyists now tend to avoid `method_missing` and `const_missing` when possible, and abandoned the craze of making everything a DSL. The most meta-programming that Rubyists still use on a regular basis is defining `self.included` on modules in order to inject other modules. Also, Rubyists have embraced API documentation, such as YARD, in order to document and communicate any "magic" that might exist or occur.
There is a significant anti-Ruby sentiment in the tech industry right now, especially in certain fields like InfoSec, that is being pushed by a very vocal subset of the community. Whenever they see Ruby come up, they will try pushing the meme that Ruby is dead/dying/irrelevant and cite TIOBE; despite Ruby developers continuing to release new libraries, frameworks, and tooling. Or they will claim no popular websites use Ruby; apparently GitHub, LinkedIn, and AirBnB are not popular enough? Or claim MetaSploit is the only security tool written in Ruby; off the top of my head I can think of BeFF, CeWL, Evil-WinRM, and Ronin. Or claim no company uses or supports Ruby; GitHub, Shopify, Stripe all use and support Ruby. Or they will derail any positive discussion about Ruby into some intractable debate about Static vs Dynamic Typing, GC, interpretive languages, etc; even though many of the arguments against Ruby can equally be applied to Python, and yet there's no similar criticism of Python. It's really annoying and inconsistent.
Recently there was a news story about how a typo in a US military address (.mil) caused top secret emails to accidentally be sent to a similar Mali address (.ml). This blog post shows how to find all valid TLD typos using a little bit of Ruby and the ronin-support library.
There is not a Python equivalent to Ronin as a whole, to my knowledge. There are however Python libraries that provide some of the features of Ronin. For example, pwntools can be used for packing binary data and generating shellcode for exploits, however it is more of a library instead of an exploit framework (frameworks run 3rd party code and manage the control flow) and has a fairly minimal API when compared to Ronin's many libraries. There are also dozens of bespoke Python exploit "frameworks" on GitHub, but none of them that I've seen support installing 3rd party repositories of exploits. The scope of Ronin is much bigger than just an exploit framework or vulnerability scanner. YMMV
It might still be. The original metasploit developers had a habit of vendoring all of their dependencies to create a mono-repo that "just worked" (tm), even after Bundler was created, which beefed up their SLoC count. Plus there's lots of miscellaneous supporting code that was added for various past exploits. However, while some see "largest Ruby codebase" as bragging rights, wise Software Engineers will see that as a liability to be avoided.
However, Crystal aims to support the lowest common denominator between POSIX and Windows, so not all of the Windows standard APIs are supported out-of-the-box. Other Windows specific libraries will need to be created specifically for Windows users/developers.
You can write "complected" monoliths in any language. You can also write SOAs in any language. If you need native performance, Crystal is a better option, as it provides much of the same syntax, semantics, and stdlib as Ruby, but with Strong Typing. Go is a bit too simple.
- no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts.
- no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions.
- still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube).
- API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)
If you are looking for a minimal alternative to RVM, you should also checkout chruby (https://github.com/postmodern/chruby#readme). It's only ~90 LoC, supports bash/zsh, optionally supports auto-switching of Rubies, and doesn't install obtrusive bin-stubs.
Took a while to write a new blog post. Still, CVE-2013-0333 relies on the same YAML deserialization technique as CVE-2013-0156, so all the previous information is still relevant.
Not unless nginx/apache routes the request directly to public/. There will definitely be more code-paths to YAML.load, but so far ActionDispatch::Http::Parameters has been the entry point.
YAML does not allow execution of arbitrary Ruby code. Some YAML types allow specifying a custom class, which the Psych YAML parser (default in Ruby 1.9) will call the initialize or []= methods. If you can find a class that eventually evals() input passed to initialize or []=, then you win.
http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
What if I told you that there is a new web framework similar to Rails, called Fortran on Fails. It has zero vulnerabilities reported against it, ergo it must be 100% secure.