Development Multiverse

Jeff Atwood just put up a post, complete with a catchy analogy, that provides a good pedagogic overview of branching and merging. Many aspects of these concepts were discussed in the comments, most providing support for the perspective that Branching Is Hard(TM). My own perspective is that one of the chief reasons this is 'all very difficult' is because individual developers only have exposure to branching in the scope of the entire project and that exposure is most often very limited. In the absence of explicit personal experience with managing branching and merging I think it will always be Hard. Queue extolling the virtues of distributed version control...

Coming late to the dVCS party, I discovered Mercurial (Hg) a few months ago. A dVCS like Hg allows you to have full version control over your own work; the prime benefit in this context, you can easily play with different branching schemes. You find out very quickly just how many 'parallel universes' you can juggle, or at least I did (with great power comes great...blah blah blah). In this circumstance, the individual developer can acquire experience with the complete process of managing branching and merging, which will help them grok the activities within the greater project context perhaps making the process Easier(TM).

I think the discussion of version control in the general context of software engineering is an interesting one, for more discussion check out some threads on Reddit (can't find the bloody one I'm looking for right now, argh!), this essay by David Wheeler (of Secure Programming for Linux and Unix HOWTO fame), and the Mercurial Book.

Strange Assortments

Ah, the obligatory "it has been too long since I've posted anything" post... I try to approach posting by following the advise of my friend ex-P.F.C. Wintergreen, who usually detests blogs but has relented on this position as of late, and at least keep my posts somewhat oriented towards novel ideas. Sometimes it simply helps to keep writing.

I see that FX is posting at the SABRE Lablog, always interesting to read what he is thinking about or working on.

I don't often find software that is worth paying for outside of music tools and operating systems (donate!) but this is wicked cool diagramming software for OS X: omnigraffle. Go buy a copy and make your life prettier.

Haven't had much time for PDB lately, the whole school + work combination has been crazy busy. I started a project concerned with using a cVu 1000 from the dudes at cpacket to control the bandwidth usage of network flows. I have other more fun ideas for this device... suffice it to say that it is always fun to make networking products earn their rack space.

Porting PDB to OpenBSD Act I Scene II

The need to run Matlab necessitated bringing my PowerBook back from the land of music and sound design... So, with a fresh install of Tiger I now have a box running an OS that implements divert sockets... Getting PDB up and running while my physical layer class works on examples of free space loss (and their arithmetic skills) seems like a great way to make use of the day.

Quick and dirty process to get PDB up and running on OS X:

• Step 0 - clean out bleeding edge cruft

Clean up the build dirs for libcii and libfmt. Build those libs from the Makefiles in their respective directories; the top level make file isn't set up to do it (yet).

• Step 1 - rbconfig.rb is broken by default in Tiger. Fix it.
  

• Step 3 - where, oh where is ruby.h?

I didn't save the output from make, but the gist of it is that with the latest Xcode and the transition to universal binaries our lib path is messed up. Ruby header files are now in universal-darwin8.0 not powerpc-darwin8.0. Just symlink it all:

ln -s /usr/lib/ruby/1.8/universal-darwin8.0/* /usr/lib/ruby/1.8/powerpc-darwin8.0/ 

Now we're ready to get to business with PDB...

The 'pdb' executable is actually a little shell script that has functions for adding/deleting ipfw divert rules and running pdb (nee iledit). I wanted to do a little simple testing with a clear text protocol so I changed the divert rules to accomodate passive FTP:

~/tools/src/pdb-0.0.1.bleeding-edge$sudo ./pdb
==> Adding ipfw divert rules...
00242 divert 4642 tcp from any to any dst-port 21 out
00243 divert 4642 tcp from any 21 to any in
==> Running pdb...
hi pdb-ruby.bundle
hi ip.bundle
(pdb) c
                        45 10 00 38 20 c5 40 00                      E..8..@.
                        40 06 00 00 c0 a8 01 03                      @.......
                        81 80 05 bf c0 60 00 15                      .....`..
                        98 d3 dd f7 82 18 d1 3c                      .......<
                        50 18 ff ff 54 5f 00 00                      P...T_..
                        55 53 45 52 20 61 6e 6f                      USER.ano
                        6e 79 6d 6f 75 73 0d 0a                      nymous..

..SNIP..

(pdb) exit
I am slain!
==> Removing ipfw divert rule...
~/tools/src/pdb-0.0.1.bleeding-edge$

Excellent! More experimenting to come... time to read some code.

Porting PDB to OpenBSD Act I

Originally published on Sunday 13 August 2006:

So Jeremy Rauch of Matasano has released a wicked cool piece of kit for network protocol (and vuln dev) geeks like myself called PDB. Follow that link and you can also find the pdf of his blackhat talk. I was quite chuffed to have a tarball in my hands after eager anticipation at the announcement of the talk... I ran into a little problem.

We always hope that upon downloading and unpacking a new tool we can just do

./configure && make && make install

(or even just make) and it will just fscking build. That isn't what happened with PDB, this is:

~/proj/rb/pdb-0.0.1.bleeding-edge$make
cc -I/usr/local/include -Icii/include -g  -c iledit.c
iledit.c: In function `main':\r\niledit.c:220: error: `SIGINT' undeclared (first use in this function)
iledit.c:220: error: (Each undeclared identifier is reported only once
iledit.c:220: error: for each function it appears in.)
iledit.c:221: error: `IPPROTO_DIVERT' undeclared (first use in this function)
*** Error code 1

Stop in /home/meltzer/proj/rb/pdb-0.0.1.bleeding-edge.

Ok, fine. We obviously need to include signal.h to get SIGINT, but we have a serious problem with IPPROTO_DIVERT; OpenBSD doesn't do divert sockets. I believe that there are patches to add divert sockets to the Linux kernel (may be stock now too) and there is a nice mini-HOWTO; OS X and FreeBSD also do them, see divert(4).

I have a powerbook, but am somewhat sorry to say it is currently my 'everything aside from hackery' machine so this has to work on OpenBSD. Don't even suggest running Linux.

So, how can we make this work? From my brief research there seems to be two alternatives short of a little, or lot, of kernel kacking and both involve virtual interfaces: pflog0 and tun0. Mikle Frantzen gives the rundown on pflog0 and pcap along with little pseudocode here.

In the context of divert sockets in general, doing something like:

mysocket = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)

would be much nicer than messing with pseudo-devives. I'm going to have to a bit more investigation to see how I want to approach this. Stay tuned."