> I can see how you could think that. You are wrong, however. > The point of what I wrote is that you cannot run arbitrary code, > because the type system forbids it. When I say "types", people often > misinterpret me to be talking about representation types like char & > int - it is far more interesting to discuss types that categorise > classes of functions, because you can talk about what a given function > may do in a much more granular way.
Sorry I obviously didn't phrase my point correctly, it's not about the execution of arbitrary code, but more about the decision chain that lead to the vulnerability in Rails. If you perform actions based off user input you are subject to having to sanitise that input. The kind of mistake that was made in Rails is capable of being made in any language, you might not end up with arbitrary code execution, but you can still have serious implications for your application. Cheers Jon ----------------------------- [email protected] jonrowe.co.uk On Saturday, 9 February 2013 at 11:55, Mark Wotton wrote: > On Sat, Feb 9, 2013 at 10:33 AM, Jon Rowe <[email protected] > (mailto:[email protected])> wrote: > > It's not Ruby's fault that an early design decision in Rails lead to a > > security vulnerability. Any language where user input can be interpreted in > > some fashion runs into this kind of issue. This was a complex chain of > > things working correctly that lead to a undesirable unanticipated situation. > > There is every chance a strongly typed language could have a similar > > vulnerability. > > > > > I can see how you could think that. You are wrong, however. > The point of what I wrote is that you cannot run arbitrary code, > because the type system forbids it. When I say "types", people often > misinterpret me to be talking about representation types like char & > int - it is far more interesting to discuss types that categorise > classes of functions, because you can talk about what a given function > may do in a much more granular way. > > This is the theoretical advantage. The engineering advantage is that > the type system lets you know when you're doing staged programming > (effectively what is happening with the YAML example), and makes you > consider whether the advantages of the flexibility are worth the extra > complexity (both in types and code). > > > The Ruby ecosystem and community meant this was fixed quickly, and urgently, > > and I think you'd be silly to think that the Rails core team isn't taking > > this seriously, the amount of new vulnerabilities currently coming to light > > is due to a large amount of volunteer scrutiny focused on a new attack > > vector that wasn't really considered before. > > > > > Yes, agreed. The reason I hang out with you lot is everything to do > with the community and nothing to do with the language :) > > mark > > -- > A UNIX signature isn't a return address, it's the ASCII equivalent of a > black velvet clown painting. It's a rectangle of carets surrounding a > quote from a literary giant of weeniedom like Heinlein or Dr. Who. > -- Chris Maeda > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > (mailto:[email protected]). > To post to this group, send email to [email protected] > (mailto:[email protected]). > Visit this group at http://groups.google.com/group/rails-oceania?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rails-oceania?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
