When GitHub announced the introduction of 2FA, I decided to wait for a few days before trying it (you know, shutting yourself out of your own account is like closing the door with your keys still on the kitchen table: it’s not funny).

Setting up 2FA is easy and quick; the only thing I’d like they changed is the fact that those recovery codes should not be still accessible in the settings section, imho. But I’m digressing.

The first thing to notice is that, unfortunately, the most famous Android applications for GitHub (the official application, Hubdroid and Octodroid) do not currently support 2FA and thus they’re unable to authenticate after you’ve activated it; easy workaround: authenticate them before switching 2FA on.

Interacting with the APIs is a bit different: Basic Authentication is still usable, but you need to pass the OTP in a specific header and if you have a very long script with multiple commands, that OTP is going to expire too soon; authenticating via OAuth is still the same however.

At this point I started playing a bit with the latest Octokit gem, which changed quite a lot starting with version 2.0.0, and wrote some toy scripts.

The first toy was this:

If you’d already activated 2FA, it asked you an OTP and retried. It worked, but that OTP expires quickly and you’d have to add the X-GitHub-OTP header to each request. Unrealistic.

Using OAuth2 tokens is much better, so my second toy first used Basic Authentication to create a brand new token and then used it to iterate over some repositories:

This second toy assumes you’re using 2FA and creates a lot of garbage over time in your Personal Access Tokens panel: those tokens are clearly labeled as “Disposable”, but it’s not funny to have to remove tons of tokens after some months of use, is it?

Maybe reusing a single token is better, so my third toy used Basic Authentication to retrieve an existing token, aptly named “Toy 3”, from GitHub and then used it over and over again:

Storing a token locally instead of grabbing one from GitHub (and thus having to type a new OTP each time you have to use a script) is probably better. Where could it be stored? .netrc could be an option (it’s a portable solution, fully supported by Octokit gem), but… These days I use a Mac, so after a while I started thinking that using OS X’s keychain is, maybe, slightly better than having your token in a plain text file and so I added a token to my default keychain with some optional flags to clearly make it stand out:

Then my fourth toy used the security command to retrieve that token:

I’m not 100% sure that the find-generic-password sub-command has the -w flag even in older OS X releases; anyway, when this fourth toy ran, I was asked to grant security access to the token (because of that -T flag security was not automatically authorized) and then the script went on without issues.

I purposely used the -D flag to specify a “custom” kind instead of mixing the token with the other application passwords when creating the item and tried to identify accurately the entry for find-generic-password: changing values for -a and -s it should be possible to add more than one token, if necessary.

So, in the end, I can say that using GitHub’s APIs with 2FA is slightly more inconvenient, but not too much to force someone to turn it off and that I spent some pleasant time playing with the Octokit gem and getting to know it a little bit better.

Once in a while I check the optiboot project and I’m glad to see it’s active. Today I saw version 5.0a had been released some weeks ago and so I thought it was due time to recompile and replace it on my toy board.

Let’s review the official instructions:

• I don’t have a single Windows system, so I cannot say anything about that world;
• for Mac, if you use MacPorts you don’t need CrossPack: just install the avr-libc port (if you use Homebrew, you’ll have to search for a good formula);
• for Linux (let’s say a Xubuntu 13.04 for argument’s sake), you need to install the avr-libc package (which depends on the gcc-avr package; if you installed only the latter, you wouldn’t be able to build the bootloader).

Official instructions hint to use Arduino IDE’s AVR GCC: I’ve never been able to make it works and it’s older than what can be installed on Mac and Linux, so let’s forget it (and after all, setting up a minimalistic local development environment is not so hard, isn’t it?).

Anyway, after you have a working compiler, it’s just a matter of running make with the right target; and given that these days UARTs are configurable, building a bootloader which uses another UART is a breeze:

Awesome!

Some weeks ago I received this little MCU:

Compared to ATmega328P, this ATmega1284P is not really a “little MCU”, it’s big (and I’m not talking about the physical dimensions):

Health, work and “real” life plotted against me and so I haven’t been able to play with it until recently. Anyway, after quickly connecting an Arduino Uno and this ATmega1284P via the ICSP interface, here’s the abriged content of that chip out of the box (courtesy of the ATmega Board Detector sketch):

Standard fuse setup and “blank” program memory: everything looked in order.

Unfortunately there seems to be a “plague” which affects ATmega1284P’s first UART and so, even if the chips was running at just 16 MHz, after burning a version of the Optiboot bootloader prepared for this MCU, I couldn’t load any program via RX0/TX0. A way to mitigate this problem seems to be adding a 10 kΩ resistor and a 100 pF capacitor, which I didn’t have at hand, so I don’t know if they would have been the right solution to my problems.

I tried lowering the speed in vain, but perhaps I didn’t reduce it enough because later I haven’t had any issue with using the first UART to communicate with peripherals or the serial monitor…

Fortunately, tweaking Optiboot’s code to use RX1/TX1 was not very difficult (but I would have saved some time if I had checked the project’s page beforehand…) and so after a while I was able to load programs without problems. Here’s what the ATmega Fuse Calculator sketch running on ATmega1284P says about the Arduino Uno board’s chip:

Writing small sketches and playing around with Arduino is funny, but I was curious about reducing the component numbers, the board size and skipping the bootloader to recover those precious 0.5 KB.

It turned out it’s quite simple, even if there are contradictory informations scattered around the net.

Armed with the following board definition (which works flawlessly with versions 1.0 and 1.0.1 of the IDE), an Arduino Uno, a breadboard, a brand new ATmega328p, a bunch of wires, a crystal, some capacitors, an LED and a couple of resistors I was able to upload a sketch without any bootloader and see it working :)

A better name could be “ATmega328p (16 MHz, w/o bootloader)”, but for someone like me who’s still wet behind the ears, “Arduino Uno (w/o bootloader)” seems better :)

Not bad, not bad at all… and, more importantly, funny :)

It arrived yesterday morning…

I knew it was small, but having it in your hand is another story (and the facts the the project started here in Italy and that the board is built in Italian factories reminded me that, sometimes, we Italians are not so bad at what we do with passion).

And now difficult part: I must try not to fry it or electrocute me :-)

…at least for my little apricot tree and its elusive guest spider :-)

Removing a lot of EBS snapshots by hand with AWS’s web console is not really funny, isn’t it? Scripting it with fog is easy, but this time I decided to try the aws-sdk gem.

aws-sdk is AWS’s official SDK for Ruby. It’s definitely a late addition and I didn’t pay to much attention to it when it was announced some months ago, but being an official AWS’s product, maybe it’s in a better position to follow the evolution of the many AWS’s web services. Anyway, after quickly scouring the online API docs and setting the right environment variables with AWS credentials, I wrote a bunch of lines in IRB and, voilà!, the unneeded snapshots were removed.

Here’s an edited version of that bunch of lines:

Simple, short, and above all else labor-saving.

I still like fog and I think it’s a great library, but, maybe, aws-sdk is not so bad after all and it deserves more study.