ActiveState has created a Tcl Extension Archive tool called teacup which simplifies the installation of binary extensions to Tcl. It’s included with ActiveTcl, but if you’re using Tcl from MacPorts and want to use teacup, it’s fairly easy:

1. Download teacup for MacOS X

The teacup binary can be downloaded from this location:

• http://teapot.activestate.com/entity/name/teacup/index

Here is a direct link to the latest teacup binary. The file is named file.exe — simply rename that to teacup and put it in /usr/local/bin or another convenient place in your $PATH.

2. Create the installation repository

You will need an installation repository where teacup can store its data locally. The default location is /Library/Tcl/teapot and you can create it like this:

$ sudo teacup create
Repository @ /Library/Tcl/teapot
    Created

3. Patch MacPorts tclsh to handle teapot repositories

$ sudo teacup setup /opt/local/bin/tclsh
Looking at tcl shell /opt/local/bin/tclsh ...
  Already able to handle Tcl Modules.
  Already has the platform packages.
  Patching: Adding code to handle teapot repositories ...
Done

4. Link teacup to MacPorts tclsh

$ sudo teacup link make /Library/Tcl/teapot /opt/local/bin/tclsh
Ok

That’s it! You’re done. You should now be able to list available packages within TEA using teacup list and install them using sudo teacup install "packagename".

I’ve tested this on MacOS X 10.6.1 Snow Leopard with Tcl 8.5.7 from MacPorts.

Tags: HOWTO, Tcl, ActiveState, TEA, teacup

I’ve been using djbdns and qmail for many years, specifically because after reviewing its code and comparing it to other possible alternatives, I objectively decided that these two pieces of software are superior in all aspects.

Lots of people have cast aspersions on D. J. Bernstein and his software, usually with emotional and irrational claims. Of course, most of these people can’t even read code well enough to understand what it does or how it does it. However, when you encounter the opinions of actual programmers, we all tend to share a similar but different opinion.

Today, Aaron Swartz put this into words better than I could: D. J. Bernstein is the greatest programmer in the history of the world. The money quote:

[...] djb’s programs do not work like most programs, for the simple reason that the way most programs work is wrong.

Amen.

Tags: D. J. Bernstein (djb), djbdns, qmail, Aaron Swartz

I needed to re-enable service updates on my SA2 TiVo tonight and I’d forgotten how to toggle it after having disabled them when I first hacked my TiVo, and had a tough time finding the information so I figure I’ll post it to my blog so I’ll be able to find it again.

The key command is bootpage – use “bootpage -p /dev/hda” to see the current settings. Then, use “bootpage -P "..." /dev/hda” to change them. Specifically, change “upgradesoftware=false” to “upgradesoftware=true” or vice versa.

Tags: TiVo, hacks, reference

In order to get afacli working on Ubuntu Hardy, I did these things:

1. Get afa-apps-snmp.2807420-A04.tar.gz from Dell.

2. Get libstdc++2.10-glibc2.2 from Debian afacli depends on libstdc++-libc6.2-2.so.3.

Since I’m running Ubuntu x86_64, I put libstdc++-libc6.2-2.so.3 in /usr/lib32. Installing the rpm package under Ubuntu provides rpm2cpio which I used to extract afaapps-4.1-0.i386.rpm like this:

$ rpm2cpio afaapps-4.1-0.i386.rpm | (cd / && cpio -iudvm)

That’s it. You now have /usr/sbin/afacli.

Tags: Linux, Ubuntu, Adaptec, afacli

Last week, I decided to take a stab at implementing a basic OAuth consumer in order to integrate Twitter Karma with Twitter using OAuth. I’d read through the OAuth 1.0 specification before, but never closely enough to realize that there was a serious attack vector in it. So, I mentioned this on the twitter-development-talk mailing list, hoping to get some answers on April 16th:

Also, the redirect to the callback URL has no signature. What stops an attacker from brute-force attacking an OAuth consumer, iterating through posisble tokens? Simply the large search space of valid OAuth tokens? Even if it’s only “possible in theory” … some teenager with nothing better to do is going to eventually turn that theory into practice.

My concern was met with confusion so I brought the concern to the OAuth mailing list (also) on April 17th:

Currently, the OAuth callback URL is susceptible to replay attack and token shooting. Signing it would eliminate this in a very low-effort way.

…

[...] it’s very desirable to be able to tell if the callback was legitimate or either a replay attack or a brute-force token shooting attack.

Even client-side browser cookies may not win here if a simple session fixation attack is coupled with the token shooting attack.

I wasn’t sure if I was being understood, either, but then a few days later on April 20th, Twitter yanked their OAuth support offline.

Eventually, an OAuth security advisory 2009-1 was published on April 23rd that clearly states “A modified specification to address this issue is forthcoming” as I pointed out was necessary, and Eran Hammer-Lahav writes a thorough explanation of the problem in his blog. The money quote:

If we put it all together, even if an application:

• Makes sure to use the account of the user coming back from the callback and not that of the one who started
• Checks that the user who starts the process is the same as the one who finishes it
• Uses an immutable callback set at registration

It is still exposed to a timing attack trying to slide in between the victim authorizing access and his browser making the redirection call. There is simply no way to know that the person who authorizes is the same person coming back. None whatsoever.

This is exactly why the callback URL that the OAuth provider uses to redirect the user back to the OAuth consumer needs to be signed.

So, why am I making a big deal out of all of this? Well, I’m irked. Coincidentally, their “discovery” of this issue conveniently coincided with my raising of the issue publically on the mailing lists, yet nowhere is my name mentioned in any of this. In my opinion, that’s really poor form in an “open community” where often the only compensation for effort is recognition. It’s this kind of back-handed treatment that encourages people to demonstrate these security concerns through actual working exploits, which benefits no one but guarantees the creator their recognition.

In the end, I’m glad that this issue is going to be addressed and hopefully in a timely fashion because all of us developing applications in the public software ecosystem will benefit, but I still feel slighted. I’ll get over it, while I wait for the OAuth 1.1 specification.

Tags: OAuth, Twitter, security