Doesn't this already require to be "on the other side of the airtight hatchway", or am I missing something?<p>The Marshal.load docs explicitly have a warning that you should not pass it untrusted data: <a href="https://docs.ruby-lang.org/en/master/Marshal.html#module-marshal-security-considerations" rel="nofollow">https://docs.ruby-lang.org/en/master/Marshal.html#module-mar...</a>
Which brings us to the old saying: Do not deserialize untrusted data.<p>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<p>This mindset is changing, in the npm ecosystem, managing and updating dependencies have become somewhat of a gamble. It is no longer <i>if</i>, its when you are compromised.
Checksumming the dependencies in the Gemfile may help. <a href="https://blog.rubygems.org/2024/12/19/bundler-v2-6.html" rel="nofollow">https://blog.rubygems.org/2024/12/19/bundler-v2-6.html</a>
Gems/packages should explicitly declare what kind of features they need/want (file, net, deserialization, execute)<p>And when the sig. changes, you should get a warning<p>Very similar to the iOS entitlements
> Do not deserialize untrusted data.<p>I think the better lesson is "use safe codecs"
LLMs: hold my beer
Quoting the ruby documentation:<p>> Marshal.load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.
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?
[dead]