The nature of software is to always be evolving. COBOL jokes aside, it’s rare to find programming frameworks that reach a level of maturity and support that allow them to just exist without being supplanted by a newer language or a better abstraction. Which naturally is great. Who wants to find themselves writing software with the expectations of today while performing the tasks of manual memory management or manipulating strings that are just raw pointers in a block of memory terminating with a null (\0) character? But sometimes in this constantly evolving space, you find a framework that resonates, and you hold on to it tightly. I wanted to share how this happened for me, first with Ruby (no surprise) but then oddly with Objective-C.

source: L

What happens if we send an authenticated HEAD request to https://github.com/login/oauth/authorize? We’ve concluded that the router will treat it like a GET request, so it will get sent to the controller. But once it’s there, the controller will realize that it’s not a GET request, and so the request will be handled by the controller as if it was an authenticated POST request. As a result, GitHub will find the OAuth app specified in the request, and grant it access to the authenticated user’s data.

Help me, framework!

source: HN

Awhile back, I set out to look at Fiber performance and how it’s improved in recent Ruby versions. After all, concurrency is one of the three pillars of Ruby 3x3! Also, there have been some major speedups in Ruby’s Fiber class by Samuel Williams.

It’s not hard to write a microbenchmark for something like Fiber.yield. But it’s harder, and more interesting, to write a benchmark that’s useful and representative.

source: L

Turns out that when frozen string literals were introduced in Ruby 2.3 a couple of unary methods were added to the String class - namely unary + and -. They made it possible to have “positive” and “negative” string literals. What does this mean exactly? Let’s figure this out together!

source: L

Ruby 2.7 is coming out this December, as with all modern releases, but that doesn’t stop us from looking for and writing about all the fun things we find in the mean time! No no no. For this article, we have something that’s very reminiscent of Bash, Perl, and Scala: Numbered parameters.

source: L

See also: https://github.com/mpgn/CVE-2019-5418

See also: https://groups.google.com/forum/#!topic/rubyonrails-security/pFRKI96Sm8Q

replace the Accept header with Accept: ../../../../../../../../../../etc/passwd{{

Somebody found a way to put a path traversal vuln in the Accept header. Wow.

If only there is a way visualize the OS heaps so that I can see what’s going. Unfortunately there are no tools that allow me to do that. So I wrote an OS heap visualizer myself.

source: L

It introduces a number of new features and performance improvements, most notably:
A new JIT compiler.
The RubyVM::AbstractSyntaxTree module.

The JIT compiler aims to improve the performance of Ruby programs. Unlike traditional JIT compilers which operate in-process, Ruby’s JIT compiler writes out C code to disk and spawns a common C compiler to generate native code. For more details about it, see the MJIT organization by Vladimir Makarov.

Ruby 2.6 introduces the RubyVM::AbstractSyntaxTree module. Future compatibility of this module is not guaranteed. This module has a parse method, which parses the given string as Ruby code and returns the AST (Abstract Syntax Tree) nodes of the code. The parse_file method opens and parses the given file as Ruby code and returns AST nodes.

This blog post details exploitation of arbitrary deserialization for the Ruby programming language and releases the first public universal gadget chain to achieve arbitrary command execution for Ruby 2.x. This will be described in the following sections which detail deserialization issues and related work, discovery of usable gadget chains, and finally exploitation of ruby serialization.

source: HN

Not sure if I learned more about rust or ruby here.

Rust is telling me that iter() yielded references to integers, but my code expected an actual integer, not a reference to an integer.

Now the array was mutated! It turns out Ruby passed integers to the closure by value, but strings by reference. Updating each string inside the loop also updated that string inside the array.

I managed to be surprised by both those statements.

My idea at the beginning of the day was – what if you could take an arbitrary Ruby process’s PID (that was already running!) and start tracking its memory allocations?

source: L

I’ve been working on building a compacting garbage collector in Ruby for a while now, and one of the biggest hurdles for implementing a compacting GC is updating references. For example, if Object A points to Object B, but the compacting GC moves Object B, how do we make sure that Object A points to the new location?

source: HN

The problem manifests itself as a slow, creeping memory growth in Ruby processes. It is often mistaken for a memory leak. However, unlike a memory leak, memory growth due to fragmentation is logarithmic, while memory leaks are linear.

This starts off with a simpe problem and fix, but lots of info about what’s happening.

source: L

When programming in Ruby many people think that egregious memory usage is the norm and unavoidable. However, there are ways and strategies to keep memory usage down and in this post I will show you some of them.

source: L

Most modern programming languages have a function somewhere in their standard library for splitting strings.

What should it return?

source: L

At Diploid, we have been using Crystal for quite some time now. We would like to share our experience in this interview, answering questions relevant to companies wanting to use Crystal for production.

source: HN

This error is caused by changes in how fork() behaves in High Sierra.

Another problem that could have been avoided if people read the manual.

Some more info: http://www.sealiesoftware.com/blog/archive/2017/6/5/Objective-C_and_fork_in_macOS_1013.html

source: HN

I was surprised to learn that parsing untrusted YAML is dangerous. I had always figured it was a benign interchange format like JSON. In fact, YAML allows for the encoding of arbitrary objects, much like python’s pickle.

source: L

Everything can be patched, except the things that cant.

source: danluu

I find this interesting as a cautionary tale of how several of Ruby’s features (here, ubiquitous mutability, blocks, and nonlocal exits) interact to create suprising edge cases that need to be addressed, and how addressing those edge cases can easily result in yet more problems

source: L