Edward Thomson

CUWiN -- the Champaign-Urbana Community Wireless Network -- just announced that they've received an NSF grant to continue developing their open source technologies for wireless mesh networking.

CUWiN's mission is twofold: their first goal is to build non-profit wireless broadband networks, to bring high-speed Internet to everybody -- building on the belief that the Internet is the great equalizer of this century. Think low-income residents, developing nations, and disaster victims. People who would benefit from the Internet, but can't get it.

Thus, they've got a bunch of kernel hackers to build open-source wireless mesh routers. They're on the cutting edge of research & development into mesh networks -- and somehow they're quietly hidden in the middle of a cornfield^[1].

I trust that this grant will allow CUWiN to continue both developing their technologies and expanding their social mission. I'm both humbled and proud that Sascha and the rest of these guys are in C-U.

I'm proud to note that Teamprise 1.1 was released this morning, which adds support for NTLM2 authentication, fixes several small bugs and is released for Mac OS X as a Universal Binary.

NTLM2 is a challenge-response authentication system that is frequently used by IIS (and thus, Team Foundation Server) installs for additional security above HTTP Basic authentication^[1]. We released Teamprise 1.0 without support for NTLM2 authentication (we supported the older LM style) because Microsoft has not openly published the specification for NTLM2, and we believed that most TFS installations would not need it -- those worried about security would opt for SSL and encrypt the entire transport, not just the authentication^[2].

Unfortunately, enabling NTLM2 in Team Foundation Server - and disabling other authentication methods - seems like a win with no drawbacks, and most administrators went ahead with it. We quickly realized that Teamprise needed support for NTLM2.

Fortunately, the Samba team^[3] has documented much of the work they've done in reverse engineering of NTLMSSP^[4] for CIFS, and the Apache HTTPClient team has implemented LM authentication over HTTP. Between these two, we got a good head start, and the powerful protocol analyzer Ethereal helped us with the trial and error to figure out the rest, and we are very pleased to support NTLM2 in Teamprise 1.1.

Further additions to Teamprise 1.1 include Universal Binary support for Mac OS X -- another feature I'm very pleased with. As the Mac guy, I was a bit embarassed to release Teamprise 1.0 with PPC-only support, even though we delivered Intel Mac binaries to beta testers. Fortunately, all went well, and we're releasing Teamprise 1.1 as a Universal Binary. I believe this brings the Mac version onto a level playing field with Windows and Linux.

Teamprise 1.1 is not a critical update for those that are happily using Teamprise 1.0, but if you've been waiting on evaluating Teamprise until NTLM2 support was available, or if you're using Teamprise 1.0 on an Intel Mac, Teamprise 1.1 is a nice little release we think you'll be very happy with.

1. Note that HTTP Digest is at least equally secure -- and presumably more so, since the NTLM2 specification is closed and has not been formally peer reviewed.
2. If you are that worried about security, it is still recommended that you use SSL -- using NTLM2 alone leaves precious data flying across the wire in cleartext.
3. Special thanks to Christopher Hertel for his work on NTLMSSP
4. The terminology gets a bit hairy here, especially with the commonality in names. LM, NTLM and NTLM2 are all crypto-based authentication protocols, while NTLMSSP is the definition of the message protocol that delivers them. Ie, you receive an NTLM challenge in an NTLMSSP message, you then send your NTLM response in an NTLMSSP message.

I've previously mentioned that SWT-based Java apps need some work to run on Intel Macs. This is still true if you're building against Eclipse 3.1.

Fortunately, it's dead simple - all you need to do is download the Universal Eclipse 3.1.2 (available as an attachment to Bug 98889) and copy some of its files into your app.

First, you need the JAR containing the architecture-specific SWT jnilib. Assuming Eclipse is unpacked into /Applications/Eclipse, and you're in your app's .app folder:

If you're building an RCP-based app, you should update the Eclipse launcher, too -- otherwise Rosetta will drag along and you'll have a several second delay when starting your app. Thanks to the simplicity of the launcher - which determines class loading based on the name it's called by - you can just copy the Univeral Eclipse launcher onto your app's launcher. Assuming you're in your .app folder, and your app is called MyRCPApp:

There it is -- zip this up and you've got a Universal app. (Or better yet, update your 3.1.2 delta pack so your build process does this automatically) and you've got a Universal build.

(Sorry if this seems elementary or obvious -- I was feeling bad about not having updated my blog recently, and I thought an easy entry would kickstart me into writing more!)