"adserver on master"

I found this slip of paper in my perl cookbook a few mornings ago. It's probably from spring 2001 or so, and it was written by Brian & left on my desk.



What is it? It's a small piece of the deployment system for the first amazon ad server. Brian and I worked on it together, along with a couple other amazonians, and we all sat on one hallway on the first floor of pacmed. I was probably out walking Declan when he pushed the latest ad server software and needed a sign off before it could go out, so he wrote this note and left it on my desk. Amazon basically has three levels of deployment. First there's a test server, where all the data is from the test domain. Then there's a "master" environment that this note refers to- and finally production. Code has to be signed off on by QA (that would have been me) on the test server and then on the master server again before it can be pushed.

I'm trying to remember how I let him know that I'd given my signoff... it was probably over email. I'm not sure that the ad server got an official sign off tracking form until it was a year or two old. You'll notice that at some point over the last seven years I doodled in red in the eyes of the smiley face. I have no idea when that was- possibly while I was running the preflight, waiting for something to load. I also noticed the "please" and "thanks" in this note - despite all the protests he'll give you, Brian is really a southern gentleman at heart.

This has brought back a lot of great memories from our initial launch of the ad server and the first year that it was up. Making apricot scones the weekend before launch for our Sunday AM bug bash. Our friend Greg, who was a web dev at the time, naming the templating language that we wrote ads in. (It's called "schusteranto" after Brian. Pretty cool that he has a programming language named after him, even if it is just an tiny substitution language.) Sitting directly behind PacMed's espresso stand, which was sooo handy sometimes. Declan learning how to play frisbee, instead of running away terrified from one when you tossed it. Walking home from work at 8 PM that summer, as the dotcom crash kept going, watching the sun setting while I walked up 2nd Ave. Seems like yesterday in some ways.

cultures

I've been thinking for a long time that I should blog a couple of the more amusing culture clash exchanges that my sailor and I have shared. Let's be serious, the dotcom world and the military are... um... different. Vast chasms of different. We've gotten a lot of humor out of how each of us lives in opposite worlds over the last several years.

My favorite of all time was in August 2004, when I was sitting on the floor of the bridge of a boat that he was XO on, wearing jeans and flip flops, and working on my laptop. There were a couple sailors visiting from a nearby station and I chatted with them for a while. They were talking about how sad it was that I was usually stuck in an office on land during the day. I countered with 'yes, but I go to work in flip flops all summer.' Sadly that didn't sell them on the wonders of dotcom civilian life. I think they must have been imaging slipping on the deck wearing flip flops during a big storm and falling into the water- not something I worry so much about in my job.

This morning Brian and I were talking about annual reviews and how our career goals could kind of be summed up as 'write a lot of interesting code.' My sailor is also writing his version of annual reviews, for the LTJGs who work for him, and he didn't think 'write interesting code' was a valid career goal. I think his exact words were 'honestly, if you were in the CG, you would be kicked out for that. it doesn't show leadership.' Yes, because leadership is exactly what you need when you have a crashing webserver. Well, ok, you need some leadership, but you have a more pressing need for super sharp nerds.

Sunshine

Declan
Originally uploaded by wck

A sunny sheltie for a sunny March day.

python dictionaries

This is yet another 'putting things on my blog so that i can find them again' post. And because I remember stuff better once I've written it out.

I'm really a perl developer at heart, so I think in terms of hashes (you can see the post right tools for how nuts I am). Python, which I'm using for a little project I dreamed up to torture myself make my life easier, doesn't Do Hashes like perl does. Instead, you use "dictionaries".

I just borrowed o'reilly's python pocket reference from another developer, and here are the notes from the dictionaries reference in it.

adict = { 'info': { 42: 1, type("): 2 }, 'spam': [] } ==> adict['info'][42] is "1"

adict = dict(name='bob', age=42, job=('mg', 'dev'))

adict = dict(zip('abc', [1,2,3]))


Operations

adict.has_key(k) or k in adict

print d.get('key', 'not found')

adict.setdefault(key, []).append(number) (use value if it's in there, otherwise add to it)

adict.keys() -list of keys
adict.values() - list of values
adict.items() - list of k,v pairs

adict.clear() - wipe it

adict.copy()
adict.update(anotherdict) or adict.update(k1=v1, k2 = v2)

adict.popitem() - arbitrary item

adict.pop(k, [,x]) = get value stored at k (and remove k) if it was in there. otherwise, return x

adict.fromkeys(seq, [, value]) - new dictionary with keys from "seq" and values all initialized to "value"

adict.iteritems(), adict.iterkeys(), adict.itervalues() - go over the sets


(this is also mixed with things from the python cookbook)

xsrf nerdery

I haven't posted anything interesting webappsec related in ages, so I'll make it up with this super fun link that I just found.

"Racing to downgrade users to cookie-less authentication"

As I wrote previously; I discovered that in Firefox and Opera we can exhaust the cookie limit to delete the user's old cookies.

If we assume that we will have the user browsing both a site which degrades to cookie-less auth and our malicious site at the same time then if you think about this then you can see that there is a race condition between when the server sets the cookie and the user logs in (and in some applications between when a page is served and the next html request is made).

The question is; can we win this race?

I was hooked before I even got to that part, because this a great little article on exactly the type of security chaos and fun you create with a web browser. I'll add a note that I know that my current employer's website isn't vulnerable to this, and I know that solely because of some buggy JMeter scripts that I dealt with a few months ago. Something to play with anyway.

Enough browser silliness, here's a picture from my trip. I took this when my feet were pretty much walked off and I stuck over to a window of the Louvre to try to rest my toes by sitting on a nearby bench.



I love all the statues on the outside of the Louvre. On this trip I actually walked almost entirely around the outside of the building just to read the visible names of the ones low enough to street level.