Crusty Blaa

(Jaysus, thats a very long name for a few hundred lines of
code)

I've just finished hacking on what was a really interesting little
project. Basically, its a GConf backend which uses information in
the user's LDAP entries to generate the mail account configuration for
Evolution. The idea is that if you've a large number of users, all you
have to do is stick each user's email address, incoming mail server and
outgoing mail server in her LDAP entry and Evolution should just
magically work.

I'm really happy with how well this thing turned out. I mean, it
actually works, it didn't take much code, there wasn't anything
lurking in GConf or Evo waiting to stab me in the back ... and, most
of all, it should actually be very useful.

The code is in evolution-gconf-ldap-backend
in GNOME CVS and more details are in the README.

What's more, Dave Malcolm has also written some cool
scripts to solve the same problem, but without LDAP.

So, I just plowed through a few hundred emails in my gnome-panel bugzilla.gnome.org folder. In one
sense it was incredibly boring, because I don't think I actually
interacted with a single bug report, but in another sense its was just
incredibly awesome. The folder appears to be just full of bugs which
Vincent Untz has already
closed. Rocking!

I didn't know Vincent had a blog, interesting. I'll need to
polish my French a bit to understand it, though. About all I could
understand was "J'adore vim". I guess its a good thing he
uses vim, really. If he used emacs he'd put us all to even more
shame fixing even more bugs.

Discovered something interesting yesterday while trying to figure out
why Sabayon wasn't
working for jdennis over SSH:

• With ssh -Y, the SSH server creates a proxy X server to
  your local display which is just like any other SSH tunnel. Then
  it points $DISPLAY at the tunnel,
  e.g. DISPLAY=:10
• In order for you to have permission to access the local display,
  though, it also needs to add an xauth cookie your \~/.Xauthority on
  the remote host.
• The interesting part is that it doesn't do what you might assume
  and just forward your xauth cookie for the local display to the
  remote host. Instead it creates another cookie, sends that to the
  remote host and its that cookie which gets merged to your
  \~/.Xauthority. When you try and connect from the remote host to the
  local display over the tunnel, the SSH client compares the cookie
  in the first protocol message and if it matches the one it
  generated for the tunnel, it swaps that cookie with the original
  cookie and allows the connection to complete.

At first that might just seem like misguided paranoid delusional
crackrock, but it does actually make sense. With this cool trick, if
you SSH to a compromised machine (i.e. a machine where an attacker can
access you \~/.Xauthority), then your display is only vulnerable while
you remain logged in. Once you log out again, the compromised cookie
is useless.

Luis: Um, it appears my sound was
"broken" too.

I'm sure there's a moral to this story other than
"how fscking dumb am I?" but ...

I'm in Boston at the moment and I have to drive to work in
this this thing:

Brrr.