Archive for July, 2009

keyutils, python and you

Thursday, July 30th, 2009

Over the weekend I wrote Python bindings for keyutils. So this blog announces python-keyutils.

If you are not familiar with keyutils, it is a library that allows you to securely store sensitive information, directly inside the Linux kernel. You have a reasonable guarantee that the information cannot be retrieved from the memory or swap.

keyutils comes with a binary, keyctl(1), that gives you access to the kernel’s key management facilities. The man page describes the types of available keyrings. The ones the most interesting to the use case I had in mind were the per-thread, per-process and per-session keyrings.

The need for python bindings came when we realized that our release process requires typing the passphrase for signing packages way too many times, so there was a real need for a key agent of some sort. Searching for gpg-agent protocol specifications (or seahorse) returned some information, but nothing I could readily use (I may not have found the proper examples for speaking assuan; the end result was that I could not get anywhere in this direction).

Future versions of Conary will have the ability to read passphrases from the session keyring, if python-keyutils is installed. You can get python-keyutils from either contrib.rpath.org@rpl:2 or foresight.rpath.org@fl:2-devel (depending on whether you need the python 2.4 or python 2.6 version).

Keep in mind that I only implemented the bare minimum I needed for being able to set and get key information. There are other functions the library provides, that could be useful to have. If you find the need for one, let me know; as usual, patches will be cheerfully accepted.

The code is hosted on bitbucket and can be checked out with Mercurial.

Posted in Linux, Programming | No Comments »

Vote for Cary as the best place to play tennis

Tuesday, July 21st, 2009

Please vote for Cary!

The winner of the 2009 Best Tennis Town award will take home $100,000 to be used for community wide programming or facility enhancements that the winning entrant endorses, and the community will be recognized during the 2009 U.S. Open.

According to the town of Cary:

To support tennis, the Town of Cary constructed the Cary Tennis Park with 30 championship lighted courts, later converting one court to four permanent 36-foot QuickStart courts, making the Tennis Park the largest in North Carolina and one of the largest in the Southeast.  The Town also boasts 25 other tennis courts at four parks — Annie L. Jones Park, Harold S. Dunham Park, Robert V. Godbold Park, and Middle Creek School Park.   Furthermore, the Town has assembled top notch staff charged with operating the tennis program with a team based philosophy.

In addition to the Town’s tennis facilities, there are more than 200 tennis courts in Cary including public courts, private clubs, schools, businesses, and HOA facilities.  There are more than 20,317 people participating in organized tennis activities in Cary including Town programs, Western Wake Tennis Association tournaments and leagues, private club programs, corporate leagues and adult social leagues.  Many of these organizations work together to provide adult league play, junior league play, charitable organization fundraiser events, QuickStart tennis programs with local elementary school PE classes, Bridge II Sport’s wheelchair tennis program and local public and private high school teams.

Posted in Sports | No Comments »

python: the dangers of assert

Wednesday, July 1st, 2009

I ran into a piece of code that looked like this:

import threading

class A(threading.Thread):
    def run(self):
        self.foo()

    def foo(self):
        assert(threading.currentThread() != self, "Blah?")
        print threading.currentThread() == self

a = A()
a.start()
a.foo()
a.join()

In the original code, there was no a.foo() invocation, because that would have triggered the assertion. Or so it was thought. I added it for my own edification.

The intention was for the foo() method to be callable only from within the running thread. In my quick test above, a.foo() should have failed.

There were two problems with that piece of code. First, it was not failing. Second, in python 2.6 you get a warning whenever you use assert with paranthesis. This is very deliberate, since assert is not a function. Using paranthesis will simply pass a tuple to the assert construct, and the tuple will always evaluate to True.

Very dutifully, I removed the paranthesis, and moved on to do some other things (and I even forgot I did it). A few days later, a coworker reported problems with the code.

As it turned out, the assert was hiding a very old bug – the condition should have checked for equality, not inequality. But since the condition _and_ the error message were paranthesized, the code passed no matter what you did. Removing the warning uncovered the problem, probably 3 years later.

Posted in Babbling | 2 Comments »