asgaard

Ruby/Rails

Thu, 31 Jan 13 22:25:05 +0000

The seemingly continual stream of Ruby and Rails security issues over the last year or so has been kind of entertaining in a bad way.

The Rails community didn't enamour themselves to many people early on when many of them made a lot of noise about how other languages were stupid and Ruby/Rails was the only true way forward, out of the security issues that plague(d) applications written in PHP.

The actual exploit concerned JSON parsing - the JSON parser didn't actually exist, and instead used the YAML parser. Writing a JSON parser is an afternoon's work. It's also fun, and as far as parsers go, pretty easy (the JSON spec is tiny). It seems weird to me that one wouldn't exist.

I think Ruby and Rails sort of became a victim of their own success as they allowed and encouraged people to be writing code who perhaps shouldn't have been.

This post on HN sums it up, albeit in a slightly inflammatory way:

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea.
- Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't.
- Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than just data, and never said "Oh dear, that's a massive red flag".
- The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.
- The issue was reported to RubyGems multiple times and they did nothing.
This isn't the same thing as a complex and accidental bug that even careful engineers have difficulty avoiding, after they've already taken steps to reduce the failure surface of their code through privilege separation, high-level languages/libraries, etc.
This is systemic engineering incompetence that apparently pervades an entire language community, and this is the tipping point where other people start looking for these issues.

The New Conglomerate are rubbish

Sun, 13 Jan 13 22:26:10 +0000

Context: Planetside 2.

It would be nice if occasionally we could win. Just once. I don't know if NC is disadvantaged by the game rules or whether we just somehow attract more terrible players than the other factions. We seem to allow terrible players to get into leadership positions. I am sure other factions have this problem too, but since we're naturally a bit rubbish it hits us hard.

This afternoon we spent 10 minutes doing nothing at the warpgate (leaderspeak: "regrouping"), then a bit later, the same leader had us spend 20 minutes respawning on the uphill road between Zurvan and The Crown. Any idiot can tell you that you can't capture The Crown from Zurvan unless your enemy is asleep. The only reason people listen to them is because they have microphones. There should be some kind of blacklist nomination system in place; "this person is a disastrous leader, don't let them be in charge of anything for the next week".[...]

Composer and Packagist

Sat, 12 Jan 13 23:28:25 +0000

I've now got Luminous set up to be a Composer package, and it's available through Packagist (a PHP package repository).

I am a bit baffled by Composer in general. I understand the idea of having a package manager for a programming language/environment, and PHP is sorely missing any other kind of okay-quality repository (PHP classes, ha!). Node's npm is some form of black magic and I love it. Ruby's gem is nice for installing executables (I don't write Ruby, I tried once...). Python's easy_install seems to work. Composer, by contrast, is kind of baffling.

It's a command line program, but it's not a case of composer install package, instead you need a JSON file which defines your dependencies, then you just run composer on it. Which seems odd. Easier to move between machines, maybe, but not very convenient to just drop something into your project.

My second criticism is more frustrating to me as an author. I haven't used any of the other package managers as an author/publisher, so maybe the comparison is unfair, but here goes:

Composer integrates with Git, which is nice. When you pull luminous, it looks in my public Git repo at the tags and branches and tries to match that to the version you specified. That's nice. But it rather ignores the fact that a version control system isn't a software distribution method. It can be used as one, but many projects require additional steps to transform a revision into a distributable build.

In the case of Luminous, a revision contains several megabytes of testing code and some resource intensive testing scripts (fuzz tests). These are fine on a dev box, but you really really really shouldn't even have them on a production server; it's a trivial DoS vector, and it has other implications if your server is happy to execute those sample source code files. What really mystifies me is that although Composer allows you to specify post-install scripts/commands, *these don't execute for dependencies*, only for the root project. "Great", you think, "Luminous is the root project". Well, actually, it's not: the root project is whatever installed Luminous.

This means that when someone else installs Luminous, I cannot set up their copy.
This means that when I install someone else's library, I can set it up.

As a package provider, there is no situation that I could ever write a useful post install script, and as a package consumer, it shouldn't be my responsibility to set up other people's packages. Basically, I should be recommending that everyone writes in their composer.json:

{ 
  "scripts": {
     "post-install-cmd" : "rm -rf vendor/luminous/luminous/tests"
  }
}

But I can't even do that, because there's no space for comments in the package!

Or to put it another way git clone !== install .

I've locked down the testing directory as much as I can, but even so...

You could argue that I shouldn't be allowed to run arbitrary code on other people's computers, but then I would question why you want to install my libraries.

Luminous 0.7.0 release

Sat, 12 Jan 13 18:33:19 +0000

I finally got around to getting 0.7.0 out.

Highlights (pun):

SCSS (nested CSS) scanner
CSS and markup cleanup
Composer package
Licensing change, GPL => LGPL. In my eyes, using Luminous is akin to dynamic linking, and dynamic linking is okay by the GPL. But there is a certain amount of controversy around that. The LGPL is probably more appropriate in definite terms.

Download from the normal place.

Please note: the online demo will still use 0.6.7 for a while as I need to migrate the existing highlights to 0.7 (as the stylesheets are different).[...]