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:
Compared to ATmega328P, this ATmega1284P is not really a “little MCU”, it’s
big (and I’m not talking about the physical dimensions):
Feature
328P
1284P
SRAM
2 kB
16 kB
Flash
32 kB
128 kB
EEPROM
1 kB
4 kB
UART
1
2
IO Pins
23
32
Interrupts
2
3
Analog Inputs
6
8
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 :)
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 :-)
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.