Which brings us to the old saying: Do not deserialize untrusted data.
In the context of Rubygems and their specs this obviously is harder to manage but dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base.
> dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base
This mindset is changing, in the npm ecosystem, managing and updating dependencies have become somewhat of a gamble. It is no longer if, its when you are compromised.
Doesn't this already require to be "on the other side of the airtight hatchway", or am I missing something?
The Marshal.load docs explicitly have a warning that you should not pass it untrusted data: https://docs.ruby-lang.org/en/master/Marshal.html#module-mar...
Yes, but that doesn't mean defense-in-depth isn't worth doing. The article discusses how known gadgets were removed in the past.
Which brings us to the old saying: Do not deserialize untrusted data.
In the context of Rubygems and their specs this obviously is harder to manage but dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base.
> dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base
This mindset is changing, in the npm ecosystem, managing and updating dependencies have become somewhat of a gamble. It is no longer if, its when you are compromised.