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.
That's actually crafty. I wonder what the rationale was for the C function time_mload(). Anyone able to find out? How can we see which person created it first?
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...
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.
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.
And when the sig. changes, you should get a warning
Very similar to the iOS entitlements
I think the better lesson is "use safe codecs"
> Marshal.load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.