Skip to content

RSVP

A man boarding a train

The situation had soured. Tony Six and his goons had known I was coming for four hours which means anyone that owed him a favor or had a score to settle with me was already on their way and settling in to wait. It wasn’t the kind of party I liked to crash but you don’t always get to choose the venue. I had one ace they wouldn’t be expecting. They didn’t know I’d have a train.

Tagged ,

Mozilla t-shirt time capsule

I moved around a lot over the past year and ended up putting a bunch of old t-shirts into a trunk and forgetting about them. My one-o-clock-in-the-morning brain decided now was a good time to go through the trunk and get rid of all those old shirts I never wear. It turns out we Mozillians used to really like making t-shirts. Below is a pile of shirts I found from around 2005-2011 or so. How many can you identify?

Mozilla Shirts

Tagged

A successful first FLOSSHack

A few months ago Tim Morgan emailed the Portland OWASP chapter and suggested that we organize a meeting where everyone could get together and audit some existing software. When vulnerabilities were found we would follow the responsible disclosure life cycle and notify the maintainers before publicly disclosing. It would be a fun way to spend an afternoon, people would get experience with responsible hacking, and the software maintainers would have the opportunity improve their software. The idea gained traction and FLOSSHack One was born.

I coordinated with Ushahidi, an open source mapping application, to be the subject of the audit. They were very helpful, even participating during our meeting and answering questions about how their application was built. We had about ten people show up on a Sunday afternoon and everyone got to work in a supportive environment for penetration testing. By working with the developers we were able to cover a lot of the code and came up with several vulnerabilities to report which will be announced on security.ushahidi.com as appropriate.

Thanks to Tim for organizing the FLOSSHack, Ushahidi for supporting us on their end, and thanks to everyone who participated. If you’re interested in doing your own, Tim wrote this generic wiki page which should help.

Tagged , , ,

Adding a debug language to ȧḓḓ-ǿƞş.ḿǿzīŀŀȧ.ǿřɠ

Last week Greg Koberger finally got me to cross “add a test locale to AMO” off my list – and it turns out it only took a few minutes of actual coding. It sounds like others have had some troubles so I wanted to run through what I did.

Firstly, you can see what I’m talking about at the AMO dev site. I’m using a script in the Translate Toolkit called podebug to generate a .po file filled with unicode characters. You can also generate one which surrounds the strings with “xxx” or blanks them out, etc. The goal is to easily see what strings on your website can’t be localized (this means they aren’t in the .po files for localizers).

If you’re using product-details to get locale names make sure you’re using the latest revision – I added dbg to the array so it will show up in language dropdowns like all the other languages. After that I added dbg to Django’s LANGUAGES define[1]. At that point the language showed up, but we’d get tracebacks if we tried to format money in a string since ‘dbg’ was a fake language. AMO uses Babel for details about each locale so I just made a wrapper for the Babel Locale() function and told it to use ‘en’ if it saw ‘dbg’. This way ‘dbg’ is used for all the strings on the site but for any complex formatting we fall back to en. This works since dbg is based off en anyway, as far as pluralizations are concerned. You can see my commit which added that function and made sure we started using it here.

This also works on the marketplace.

[1] I actually added it to AMO_LANGUAGES which gets to LANGUAGES in a slightly round-about way. See our settings.py file for how that flow works.

Tagged , , , , ,

How to get a development instance of AMO set up in about 10 minutes

Last year we set up landfill.amo to give contributors an easy base to set up the addons.mozilla.org site. Easy is relative here, of course, but it was a big leap over what we had at the time.

Kumar leapfrogged that milestone by adding Vagrant configuration scripts to our repository. Now you can have a running version of AMO on your local system in about 3-5 commands[1].

Check out the steps to install AMO with Vagrant to see how. I set it up on OS X last week and aside from waiting for the download it only took a few minutes. Drop by #amo on IRC if you run into any troubles.

[1] Setting this up on Windows is apparently more difficult although one contributor did find success after fighting with it for some time.

Edit: Updated the installation instructions URL

Tagged , , , ,

10 years of Irssi use and I switched to WeeChat last weekend

I started using Irssi almost 10 years ago when I first started trolling wandering around the world of IRC. My main use is to run it in a screen and stay connected all the time. To chat I’ll just ssh into the server and reconnect to the screen. Generally I leave my terminal open, stretched across the top of my monitor so it’s really wide but only about 8 or 10 lines high. This way I can keep IRC visible all day long and respond quickly to questions.

I’ve customized irssi with custom highlights and commands and all has been well, save one thing: bug 310 – vertical splits. Irssi can’t do vertical window splits and with the trends giving us widescreen monitors, horizontal splits aren’t really useful to me. The bug has been open since 2005 and I’ve all but given up on it.

Then the other day Chris McDonald claimed the unfortunately named WeeChat was superior to Irssi. I was all ready to defend Irssi’s honor but I read through the documentation and WeeChat was pretty compelling – most notably its support for vertical splits!

So, long story short, I switched last week and it’s awesome. I don’t miss Irssi at all and in fact WeeChat offers me things I never even knew I’d want (like per-buffer history when hitting the up-arrow). I’ve customized it so it essentially looks like Irssi (no nickname list, etc.) and I’ve added a lot of aliases to make it easier for me to use (mostly vim keys). If you’re an Irssi user you owe it to yourself to at least read their docs and see what you think.

Tagged

PHP is dead! (on addons.mozilla.org)

This is just a short note to recognize the long coming milestone of PHP being effectively off[1] on addons.mozilla.org. We started the migration in 2010 and just finished it up a couple weeks ago. After the major pages were completed it was hard to budget time for all the minor details we had implemented since there was so much other important stuff to do (I’m looking at you, marketplace.mozilla.org). Now that the switch is done though we can simplify our setup instructions for AMO, simplify our infrastructure, optimize apache for python only, have full unit test coverage – the list goes on.

A big thanks to all the developers who made the switch possible, and especially the ones at the end who were working on migrating PHP scripts instead of more glorious projects. Thanks to the management and all the other folks affected by the switch for being patient with the scheduling. Thanks to the localizers for dealing with the crazy merged .po files, and, of course, thanks to the users of AMO for reporting bugs when they happened and generally being an all around great community to work with.

[1] Currently all traffic is being rewritten to a WSGI handler for Python. PHP is still on the server but nothing uses it. We’ll be removing it completely in the near future.

Tagged , , , , , , ,

Choosing your own greener grass

A lot of my time is spent trying to arrange projects and schedules so we can get code shipped in a reasonable time. AMO has the blessing/curse of being broad enough that there is work to do in nearly every area on the site. Once the highest priority areas have people working on them there is still plenty of work to go around that isn’t as time critical.

Last March there was some feedback from developers about being tired of the code they were working on and eyeing other technologies but not having the time to work with them. This is a fragile balance which every manager and developer has had to struggle with. Writing new code is always sexier than maintaining old code, but the old code is the bread and butter that keeps you in business. Finding a happy medium is a noble, elusive, and unfortunately, shifting goal.

Enjoying what you work on is crucial to being happy and productive though so I’ll continue to pursue that goal.

One of the changes we experimented with at the time was to let developers choose their own focus for the quarter. We still had high level quarterly goals that needed to be done, but that left plenty of other time throughout the quarter to work on any of those areas which were all equally important but perhaps not equally as interesting. I filled up a whiteboard with ideas one morning (and left space for developers to add more) and we had a meeting later in the day where anyone could discuss the ideas and sign up for what was interesting to them. This was a short term commitment from the developers and they got to work on what they cared about. From a managerial perspective, it increased motivation but didn’t sacrifice accountability. Since I knew the focus of the developers early in the quarter, I could help clear out roadblocks that they’d meet before they even started working on their areas.

The quarter is over this week and overall the idea was a success. All the feedback from developers was positive – if you’re looking for a way to spice up the top-down approach to goal setting this was effective. It also turned the goal setting into more of a discussion rather than an edict that just shows up.

I wrote this almost 9 months ago but apparently never hit publish. So, here it is. We’ve played with it a bit since but haven’t had a large quarterly planning meeting like that because we’re mainly focused on the marketplace. Experimenting with smaller goals is a next step here, and doing the meetings on a weekly or biweekly basis.

Tagged , ,

Grave Pursuit

I read a book called Hint Fiction last year where the idea was to write a compelling story in 25 words or less. My favorite that I can remember was by J. Matthew Zoss:

I’m sorry, but there’s not enough air in here for everyone. I’ll tell them you were a hero.

I had an idea to translate this idea into photographs and tell a story within a limit of 3 photos (a generous 3000 words if we’re going by the standard exchange). I took the first two photos fairly quickly but the 3rd took me a long time to organize the scene (and get a participant). During some time off a couple weeks ago I found the time to finish the trio of photos and complete the tale.

Click on the photo below to see the whole story

Security in Depth; the first layer of addons.mozilla.org

Discussing the security measures of a public facing and popular website is usually taboo. Often owners are unsure they are following best practices, prefer not to draw attention to their site, or hope that they can maintain security through the obscurity of their code. At Mozilla we are fortunate to offer nearly all of the code in the entire company as open source software. addons.mozilla.org is no exception. This means we need to be extra vigilant with the code we write (and a huge thanks to our developers doing code reviews, the security and QA teams testing code, and the community members reporting bugs they find), but it also means I can write posts like this to explain some of the security measures we have implemented and how you can use them to make visitors to your sites safer too.

SSL Encryption: Let’s start off easy. Anytime you go to addons.mozilla.org we redirect you to https://addons.mozilla.org. Assuming you make it through the redirect safely you can be reasonably sure you’re talking to us at that point. Any data sent between your browser and us is encrypted with industry standard encryption. This seems like a freebie (I know you’re thinking, “really? you’re talking about SSL?”), but do a quick search and you’ll find plenty of financial institutions that fail to take even this most basic precaution on pages where you submit the username and password to your accounts.

Alright, let’s get more interesting. AMO has a lot of user uploaded data on it, from images to files (the add-ons themselves) to the files within add-ons (we allow you to browse uploaded add-ons on the site). If a user uploads some malicious JavaScript they’ll be able to run it in the context of the addons.mozilla.org domain which would give them access to manipulate the site and change or steal user data. We protect ourselves by using an alternate domain for user uploads – static.addons.mozilla.net. By using .net instead of .org we’ve sand-boxed user scripts onto their own domain and protected the content on .org. This is industry standard (notice how your content you upload to Google comes off of www.googleusercontent.com) and gives you a free performance boost as well.

Actually, uploaded images should get special mention. It’s a best practice to always clean and verify user data but this is often overlooked for images. Back in the days of IE6 you could actually run arbitrary JavaScript embedded in the comments of an image. This has since been fixed in the browser but poorly configured servers and applications can still pose a threat. Neal Poole demonstrated a proof of concept on a Mozilla site where he embedded PHP in an image, saved it as “image.php” and uploaded to a site. The site saved it under a /media/gallery/ directory (under the webroot with PHP enabled) and he had arbitrary PHP execution on the server. The lesson learned was always re-encode user images when they are submitted. Even if you’re re-encoding from PNG to PNG, strip the comments – it’s not worth it to find out there was something malicious in them later on.

For many sites session cookies are one of the most valuable assets behind the actual credentials to log in. AMO protects the session cookie (and most of its cookies) with two very underused options: the Secure and HTTPOnly flags. Secure simply means the cookie is only sent over a secure connection – that means that when you go to addons.mozilla.org without typing the https, your cookies (and therefore your session) aren’t sent and won’t be compromised if someone is eavesdropping. HTTPOnly means that the cookies are sent with browser traffic to AMO but the cookie is inaccessible to client side scripts. If a malicious script is somehow injected into the page this option will prevent it from stealing the session id. Assuming you don’t need access to the cookies and are running SSL these are essentially free additional layers of security for your site.

Every request to AMO returns a pile of interesting (and sometimes bleeding edge) HTTP headers. If you hit the front page, you’ll see X-Frame-Options: DENY. In a supporting browser, this will prevent someone from putting the AMO site into an <iframe> (which prevents things like clickjacking). The vast majority of sites can add this header for more free security.

In a couple examples above I say that once you get to AMO on SSL you’ll be fine but I conveniently skip all the traffic and redirects up until then. An attempt to keep people safe until they reach that point is the Strict-Transport-Security: max-age=2592000 header. This tells the browser that for the next 30 days, if you type in addons.mozilla.org without https it will automatically send it over SSL before the initial request – no unencrypted traffic at all. Support for this header is not widespread yet, but it’s in all the recent versions of Firefox and I expect support for it to expand.

I can’t mention “bleeding edge” and “headers” without a hat tip to the Content Security Policy (specifications). We’ve had it in reporting mode for a couple months as we work out what needs to be adjusted before we turn it on, but once we do, this will (again, in a supporting browser) define specific rules for what domains will have valid assets (like images, JavaScript, CSS, etc.) as well as disallow any inline JavaScript from executing. This essentially locks down XSS attacks even if someone does find a way to inject code into the page. It’s a really exciting development but not for the faint of heart to implement on a complex site at this point in time. There are still some bugs to iron out and some edge cases to clarify in CSP but it’s becoming something to seriously consider. I think Twitter is the most prominent site using it to enforce rules (as opposed to only reporting violations) at this time.

Whew, that is a pile of text and that’s just covering the extreme front end. I’m going to cut it off there to keep this from running on for pages but if there is interest I’ll write another post about more things AMO does to defend itself and its visitors, and other areas where everyone can consider adding in extra security.

In the mean time, if you want even more best practices the Mozilla Security Team has made a great wiki page for further reading about web security.