April 5, 2012 - No Comments!

Notes from PyCon

I’m a Ruby on Rails guy by day, but, in the interest of staying rounded, I’m also active within the Python community. To gain more knowledge from this community, TXI was happy to send me to PyCon, an annual conference centered around Python and the frameworks (or problems solved) utilizing it. Python is a different programming language with a different set of tools and guiding principles. But I feel very strongly that the Python and Ruby communities could learn a lot from each other, and I’m not the only one—just check out RUPY, an annual conference in Poland for both Python and Ruby.

I caught several good presentations which I feel would be valuable for all developers regardless of their choice of tools (read on for some of my notes below); however, with five talks going on simultaneously for three straight days, I’m sure I missed some great sessions that would have been more applicable to both Python and Ruby. What’d I miss? What talks did you like? Leave your thoughts in the comments or drop me a line at ross@tablexi.com.

All formal talks given at PyCon are recorded and have been posted @ http://pyvideo.org so you can tune in even if you couldn’t attend. I’d definitely recommend checking out the following talks:

1. Stop Writing Classes - Jack Diederich

Takeaways:

  • Excess classes = more cost (code costs time to make and time to maintain)
  • Namespaces are for preventing namespace collisions, NOT for creating taxonomies
  • When coming up with exceptions, try to find one in stdlib first! (165 in python's stdlib: there’s probably already one which fits your purpose)
  • Classes make sense for holding & validating related data but remember KISS

Reflections:

  • This happened all the time when I was doing Java for a living (for Steve Yegge’s fine description of the situation in Java, see: "Execution in the Kingdom of Nouns")
  • I'm guilty of this in a couple api-wrappers I've built for third party services
  • This would be one of the reasons why they're not open source yet
  • Fortunately only one consumer (another app I wrote) so api evolution can happen as needed (not all gem writers are so lucky)

2. Pragmatic Unicode, or, How do I stop the pain? - Ned Batchelder

Takeaways:

  • Unicode is here to stay
  • Unless you learn, you’ll get bitten
  • Don't just use libraries: Know what they're doing and test them to make sure they do what they say they'll do
  • Build app as unicode sandwich
  • Translate at the outside layers of your program (persistence layer and standardize on one format (unicode strings) in your code)
  • Test with unicode strings

Reflections:

  • Haven't personally been bitten by text / unicode within core Ruby itself (mercifully haven't had to dive too deeply into how Ruby handles this stuff); Rails (3) seems to encode/decode input from a browser quite well
  • Be very careful of your persistence layer for your backend
  • My particular experience: MySQL
  • The mysql gem's default encoding on a connection to mysql = latin1
  • Result: When we switched to the mysql2 gem (which uses utf8 as the character set for a connection by default) we discovered issues in our database (utf8 characters that had been wrongly put through MySQL’s latin1->utf-8 conversion) which needed to be fixed
  • Thorough writeup on the subject: "Getting out of MySQL Character Set Hell" by Nathan Kaiser

3. Certainty in an Uncertain World: Gaining Confidence through Security Testing - Geremy Condra

Takeaways:

  • CWE/SANS Top 25 list: check for these and you're WAY ahead of the game
  • fuzzdb for input test cases
  • xsser checking for XSS vulnerabilities

Reflections:

  • Security should always be a concern when the app is public. Even when it’s not, and the app is just for internal use, I generally:
    • --Don't allow anonymous users to change things (they must login and only admins can create users)
    • --"Never attribute to malice that which is adequately explained by [ignorance]" -- Hanlon's Razor
  • Just because the client is reasonably sure their users aren't malicious:
    • --Don't allow admin users to change things that will break the main site functionality
    • --Have validations, be strict with them, and test them
  • In the past, we used attr_protected liberally on attributes/columns that identify parent records to mass assignment abuse
  • Foreign keys on the same
  • Moving forward, we should probably just be using attr_accessible on fields that we know we want to mass assign.
    • --Higher maintenance code
    • --More reasonable expectation of security (same rules apply for admin users of the public websites we produce)
  • Rails protections I'm aware of that protect against things on the top 25 list (and have checked out myself in the time I've been working here):
    • --CSRF: this is something they're careful with but flaws have been found from time to time
    • --XSS (we use Haml for views where all output is escaped by default and try not to show things unescaped)
    • --Avoiding SQL Injection:
      • *Always pass arguments to .where() (hash or otherwise—NEVER use string interpolation in a where clause); I believe this will use db-level bind variables and escape things appropriately
      • *If you offload sorting / grouping to the db, have a whitelist for things that could end up in an ORDER BY or GROUP BY in those clauses and check against it (I don't think Rails/ActiveRecord escapes these, and thus potential for sql injection still exists)

Don't Take My Word For It…. Test your Applications heavily!


Here’s some further reading:

2011 CWE/SANS Top 25 Most Dangerous Software Errors
Rails Security Guide

Published by: Ross Heflin in Business, Developers
Tags: , , , , ,

Leave a Reply