On Wed, Feb 06, 2013 at 06:05:24AM +0900, marcandre (Marc-Andre Lafortune) wrote:
> I'll repeat that the proposal is for a migration path, giving Rails or any library using YAML at least a year of transition where they can call `load!` if YAML responds to it otherwise `load`.
> 
> To have breakage in production, you would need:
> 
> 1) A rails app that uses ActiveRecord's `serialize` with custom classes (how rare that is is up for debate)

Nope.  Not just custom classes, Symbols as well.  This is quite common:

  user.options[:foo] = 'bar'

Supporting Symbols is a DoS vector.

> 2) That doesn't upgrade to Ruby 2.0.0 or decides to ignore the warning
> 3) That will upgrade directly to next minor (say in one year) but not upgrade to *any* new version of Rails in the meantime
> 4) And not run any tests when doing so, nor read the release notes. If they do, and decide to maintain the same version of Rails, a one-line monkey patch restores `YAML.load` as the dangerous version.

You've left out how one would migrate.  Do they slowly migrate?  Big
bang migrate?  Without an upgrade path, you've (by definition) already
ruined their chances to see *any* deprecation warnings.

> I really don't see this as a problem.
> 
> What I see as a problem is having sites compromised.

Who would argue with this?  The security patches release do not allow
YAML to process user input.

I'm happy to provide a `safe_load`, period.

-- 
Aaron Patterson
http://tenderlovemaking.com/