Recently Normandy switched from authenticating users ourselves with boring username and passwords to using Mozilla's OIDC SSO to authenticate users more securely.

Normandy is a web service that holds a lot of influence over Firefox. Because of this, we have had a list of security features we've been working through. One of the big items on this list was to not store passwords, and do authentication of users ourselves.

We chose to use OIDC for this, primarily because it is the new hotness as far as authenticating Mozillians. It can use many sources of authentication, including Mozilla's LDAP servers, the canonical source of employee user data. This is exactly what we want to use for Normandy.

One way to authenticate with GitHub is using SSH. Your remote URLs look like git@github.com:mythmon/mythmon.com This means you get to re-use all your SSH tools to deal with authentication. Agents, key pass phrases and forwarding are all great tools.

The down side to all this is that you have to use all your SSH tools to deal with authentication. That's actually kind of annoying for automation and day-to-day sanity.

Another option to authenticate with GitHub is to use HTTPS URLs and use HTTP basic authentication. For this, you use remote URLs like https://github.com/mythmon/mythmon.com. The main advantage of this is that the URL is useful even without authentication. You can pull from this URL without authorizing (assuming you are working public repos). This means automation and tooling need fewer secrets, which is great.

HTTPS URLs are also a great way to teach people, since they have a lower barrier of entry. Anyone can type in a user name and password. Explaining SSH so that that a newbie can get started using GitHub is no fun.

I write a lot of webapps. I like to use Python for the backend, but most frontend tools are written in Node.js. LESS gives me nicer style sheets, Babel lets me write next-generation JavaScript, and NPM helps manage dependencies nicely. As a result, most of my projects are polyglots that can be difficult to deploy.

Modern workflows have already figured this out: Run all the tools. Most READMEs I've written lately tend to look like this:

$ git clone https://github.example.com/foo/bar.git
$ cd git
$ pip install -r requirements.txt
$ npm install
$ gulp static-assets
$ python ./manage.py runserver

I like to deploy my projects using Heroku. They take care of the messy details about deployment, but they don't seem to support multi-language projects easily. There are Python and Node buildpacks, but no clear way of combining the two.

My gpg key changed today. This post contains a message signed with the old key with details about the new key.

Rust is pretty cool. I don't hate writing it, like I would hate writing C++. I still get the performance benefits of a low level language. Plus it gives me the chance to work in a modern strongly typed language, without having to wrap my head around Haskell.

Of course the best way to learn a new language is to go off and write something in it^{[citation needed]}. A project I've been wanting to work on lately involves a custom made IRC server (I doubt any of the existing IRCds could do what I want out of the box). There will be another blog post with all the details about this, but for now I'd like to talk about my experience with building an IRC server in Rust.

How does IRC even work?

Before I can implement IRC in anything though, I need to know how it works. In theory, [RFC 2812][] should specify the line-level protocol, and should be enough to write a full client or server. However, for a few reasons, it isn't enough to just read the RFC.

1. The RFC was written a long time ago, and isn't exactly a modern presentation of a protocol. It focuses on some things that I wouldn't expect.

2. I'm lazy, and I'm just skimming the RFC and reading the parts that seem relevant. This makes it hard to get an over-arching picture of the protocol.

3. No one actually implements the spec. For example, irssi doesn't send the right parameters for the USER command (according to this RFC). The RFC defines the parameters as the system username, the mode of the user (as a number), an unused parameter, and the user's real name. Irssi sends USER mythmon mythmon localhost :Unknown. You made notice that "mythmon" is not a valid mode, which should be a number like 0 or 8. Yay, irssi.

…

Today, edunham posted a recipe for starting screen+irssi at boot using rc.local. That's pretty cool (and useful!), but it doesn't fit into my set up very well. I know that some time this week, my VPS provider will be doing maintenance and rebooting my shell server, so it seemed like a good time set up a more automatic persistent IRC.

My setup is different in 3 key ways: I don't use screen, I don't use irssi, and I don't (want to) use rc.local. Instead I've got tmux, WeeChat, and systemd. I figure these three things are roughly equivalent, so I set off to try and apply the same idea to my setup.

Spotify is a pretty cool music service, and I really enjoy Pulse Audio, especially when combined with tools like pasystray and pavucontrol. Together they have a bit of an annoying "feature" though.

Spotify is smart enough to link its internal volume meter with Pulse's stream volume for Spotify. However, for some reason, Spotify also links the stream's volume to the master volume for the sound device Spotify is on. Blech! That means that when you grab the volume slider in Spotify, everything on the system gets louder.

This is, I am told, a "feature" of Pulse Audio called "flat volumes", and it is supposed to do better things. In practice though, I find it doesn't work and I'd rather just control volume myself. The fix for this, luckily, is simple.

I've got a media computer in my living room hooked up to a TV. It runs XBMC Kodi. It's pretty nice, except it's hard to find a good controller for it. Wireless keyboards work, but are awfully awkward on the couch.

After some searching, I decided my weapon of choice would be a TiVo Slide remote. It's (technically) Bluetooth, so no pesky line of sight issues, has a secondary IR mode for controlling other devices (TV volume and power), has a slide out keyboard, and all of this in something roughly the size of your average TV remote.

Trouble is, this is designed to work with TiVos. It can work on normal computers, but it's a bit of pain. Here I'm going to write down what I learned getting it to work on my Arch Linux media computer.

I recently switched my blog to being hosted on GitHub Pages instead of hosting the static site myself. Along with this change, I was able to automate the rendering and updating of the site, thanks to GitHub webhooks, and Travis-CI. As always, I'm using wok for the rendering and management of the site.

My work flow now looks like this:

1. Write a post, edit something, change a template, etc.
2. git commit.
3. git push.
4. Wait for the robots to do my bidding.

It is ideal.

Knowing what is going on with git and many environments can be hard. In particular, it can be hard to easily know where the server environments are on the git history, and how the rest of the world relates to that. I've set up a couple interlocking gears of tooling that help me know whats going on.

My primary project at work is SUMO, the Firefox support site. It consists of a few parts, including a wiki, a question/answer forum, and a customized Twitter client for helping people with Firefox. It is also a highly localized site, with support in the code for over 80 languages. We don't have a community in all of those languages, but should one emerge, we are ready to embrace it. In other words, we take localization seriously.

Until recently, however, this embrace of multilingual coding didn't extend to our search engine. Our search engine (based on ElasticSearch) assumed that all of the wiki documents, question and answers, and forum posts were in English, and applied English based tricks to improve search. No more! On Monday, I flipped the switch to enable locale-specific analyzer and query support in the search engine, and now many languages have improved search. Here, I will explain just what happened, and how we did it.

Crimson Twins is a project that I started at Mozilla to power two ambient displays that we mounted on the wall in the Mountain View Mozilla office. We use it to show dashboards, such as the current status of the sprint or the state of GitHub. We also use it to share useful sites, such as posting a YouTube video that is related to the current conversation. Most of the time that I pay attention to the Twins, is when my coworkers and I post amusing animated GIFs to distract amuse the rest of the office.

Git is hard

Some time ago, I found myself in a debate on irc regarding the security of git. On one side, my opponent argued that you could not trust git to reliably give you a particular version of your code in light of a malicious remote or a man in the middle attack, even if you checked it out by a particular hash. I argued that because of the nature of how git stores revisions, even a change in the history of the repository would require breaking the security of the SHA1 hashes git uses, an unlikely event. We eventually came to agreement that if you get code via revision hashes and not via branches or unsigned tags, you are not vulnerable to the kind of attach he was proposing.

This got me thinking about the security of git. About how it stores objects and builds a working directory. What if the contents of one of the object files changed? Git makes these files read only on the file system to prevent this kind of problem, but that is a weak protection. If the other end of your git clone is malicious, how much damage could they do? If there really is a security problem here, it means that a lot of deployment tools that rely on git telling the truth are vulnerable.

For many of my projects I use the excellent nose-progressive for running tests. Among other features, it prints out lines that are intended to be helpful to jump straight to the code that caused the error. This works well for some workflows, but not mine.