Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

100% Positive

Analyzed from 169 words in the discussion.

Trending Topics

#untrusted#data#rubygems#dependencies#marshal#doesn#load#docs#should#https

Discussion (7 Comments)Read Original on HackerNews

Nextgridabout 2 hours ago
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...

Retr0idabout 2 hours ago
Yes, but that doesn't mean defense-in-depth isn't worth doing. The article discusses how known gadgets were removed in the past.
sebiwabout 2 hours ago
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.

sscaryterryabout 1 hour ago
> 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.

_joel16 minutes ago
Checksumming the dependencies in the Gemfile may help. https://blog.rubygems.org/2024/12/19/bundler-v2-6.html
wyager18 minutes ago
> Do not deserialize untrusted data.

I think the better lesson is "use safe codecs"

mono44213 minutes ago
Quoting the ruby documentation:

> Marshal.load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.