Adjust hash syntax for ruby 1.8.7 compatibility

[moritzheiber]

The newer hash syntax (key: value vs. :key => value) is incompatible with ruby 1.8.7 and thus with anything deployed on Amazon Web Services. Since the only way of configuring instances with AWS is by using Chef I would strongly suggest to retain 1.8.7 compatibility, at least until Amazon moves to using 1.9.x within its Chef environment.

There are no downsides to using the old syntax. It still works with ruby 2.x and 1.9.x.

Reference: https://forums.aws.amazon.com/thread.jspa?threadID=140115

[chr4]

Thanks for reporting this @moritzheiber! There are in fact valid arguments that speak for the new syntax, and I'm trying to stick to it wherever possible. In general, I agree that Amazon AWS should be supported by an iptables cookbook.

@sethvargo: You are the strongest rejecter of ruby-1.8 compatibility changes I know :) Can you comment on the argument that embedded Amazon AWS chef apparently only supports ruby-1.8 for the moment? (https://forums.aws.amazon.com/thread.jspa?threadID=140115)

[moritzheiber]

I'd keep an eye on their development and submit another pull request once they have switched to 1.9. I like the newer syntax better than the old one as well.

[chr4]

@moritzheiber: would a ruby-1.8 branch with this patch applied be a workaround?

Librarian/Berkshelf/Repo support specifying git branches for a cookbook.

I'd make sure it gets rebased to master on every release, until AWS updates their ruby.

[moritzheiber]

Sure. I can use a submodule branch for that (AWS doesn't allow for librarian-chef/berkshelf, just one huge repository full of custom cookbooks). Branch would be fine.

[chr4]

Here you go: ruby-1.8-compat Feel free to remind me in case I forget to rebase. Since you're keeping an eye on their development, drop me a note as soon as this branch is not needed anymore.

[sethvargo]

@moritzheiber @chr4 Ruby 1.8 is officially dead. No more security updates. No more development. No more. Chef has been Ruby 1.9+ with the omnibus installer for over a year. The fact that Amazon chose (and continues to choose) to use an antiquated Ruby version is not a motivating reason (IMO) to continue supporting Ruby 1.8 in a cookbook. They are ultimately only hurting customers, since Ruby 1.8 is not supported and will receive no further updates, including security updates. Instead of adding 1.8 support to all these cookbooks (and any new cookbooks that arise in the future), I would suggest directing energy toward the Opsworks folks and asking them to bump their Ruby version, instead of adding support for a deprecated language. The original authors have been very very very clear about not using Ruby 1.8 anymore:

Now, a majority of you are using Ruby 1.9.x or 2.0.0 (IF NOT PLEASE DO)

That's IN BOLD from the people who wrote and maintain that software. I don't think there's even an argument here.

• OSX Mavericks ships with Ruby 2.0
• Newest versions of RHEL and Ubuntu ship with Ruby 1.9
• RubyInstaller on Windows is Ruby 1.9
• Omnibus is Ruby 1.9
• As conversations at the Opscode Community Summit revealed last week, there's a very very high probability that Chef 12 will drop support for Ruby 1.8

I'd be happy to talk about it a bit more in a Google Hangout or Skype call, but that's the super blunt answer.

TL;DR Amazon is wrong and holding back innovation by refusing to upgrade; I don't think cookbook maintainers should accommodate their needs.

[chr4]

Thanks @sethvargo for commenting!

TL;DR Amazon is wrong and holding back innovation by refusing to upgrade; I don't think cookbook maintainers should accommodate their needs.

I couldn't agree more.

[sethvargo]

@chr4 @moritzheiber ironically, this just happened: https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-in-floating-point-parsing-cve-2013-4164/. Amazon Opswork's Ruby is vulnerable (I checked :smile:) to this attack vector and no new patched version is available.