GPG public key signing post-party automation with KMail

This past Ubucon’s key signing party was my first key signing party. One thing I noticed–signing keys after a key signing party is a boring repetitive task. Summarized from the Ubuntu wiki entry on typical key signing post-party protocol:

  1. Retrieve all public keys of key signing party participants, using gpg –-recv-key
  2. Compare the hardcopy fingerprint from the keysigning party to the fingerprint of the retrieved public keys, using gpg –-fingerprint
  3. Sign the key, using gpg –-sign Send the signed key back, either by
    • E-mail: export the key, then e-mail it to the key owner, using gpg –-export -a | mail -s “Your signed key” user@example.com
    • Key server: send the key to a public keyserver, using gpg –send-keys

This is incredibly monotonous—and people have to wonder why Web of Trust-based encryption is not more popular?

The Debian signing-party package provides the utility caff to automate some of this. It’s not very friendly to “desktop” users, however:

  • it’s a CLI application
  • it requires a local MTA (/usr/sbin/sendmail in particular), or an “open” SMTP server, with no support for authenticated SMTP or SMTP/SSL
  • the configuration file syntax is Perl and confusing; there are also few examples on the Internet

You could add authenticated SMTP or SMTP/SSL support to the script, but having to know how to hack Perl definitely disqualifies caffe from being a desktop-friendly application.

So, I hacked together my own key signing party script in Python that would send signed keys back to people via KMail. To use it, create a text file listing all key IDs you wish to sign, one per line. Pipe the contents of this list into the script:

cat list-of-ids.txt | key-signing-party-batch-process-via-kmail.py

The script will download each key, ask you to verify the fingerprint, and then sign it. It then will open a KMail composer window, pre-filled with the key owner’s e-mail address, a friendly template message (customizable in the script), and attached key. Review each e-mail to make sure it is kosher, and click send. Other than continuing to be a CLI program, I think this is much friendlier–the only manual work done is the creation of list of keys to sign, comparing fingerprints (this could be automated, but it seems in the spirit of the Web of Trust-based systems not to), and clicking send in a familiar desktop e-mail client.

Now for some notes…

It uses the DCOP automation features of KDE’s Kmail to send messages. You could similarly use Evolution and D-Bus, but I don’t use Evolution so I can’t contribute that bit of functionality. Mozilla’s Thunderbird unfortunately does not yet support any kind of automation features (as far as I know, anyway), so you’re completely out of luck if you use it.

DCOP with Python is a complete, utter, pain. The easy way to drag-and-drop boiler-plate code with kdcop did not work, as it appears the APIs have changed. A problem with KDE/Python dcopext’s module and multiple identically-named-functions sealed the deal for me and I gave up trying to use DCOP with Python, and instead settled for a hack of using the shell instead. I’m looking forward the one Linux desktop IPC protocol to rule them all, D-Bus, to debut in KDE4.

My script does not provide all the functionality of caffe. It, for example, does not encrypt the messages and their keys back to their owners. There doesn’t appear to be an easy way to do this with KMail and DCOP, so it’s a feature that will have to wait.

The GNOME font dialog, why?

Fredico M Quintero pointed out some serious flaws in GNOME’s font configuration dialog; the Novell Product Design wiki also describes some problems. In a sentence that fits in with what I believe is GNOME’s “simplicity mantra”, GNOME should just get rid of its useless, confusing fonts configuration dialog.

Why does it have a font configuration dialog anyway? Well, unfortunately, GNOME’s setting daemon completely ignores several fontconfig settings and instead uses its own settings for things like antialiasing type, whether hinting is used, DPI, etc. You need the font configuration dialog to change these settings, or you have to dig through gconf. Most of this was put in place probably to subvert a broken X setup; instead of implementing these hack-ish workarounds GNOME should instead push to fix X instead.

It’s extremely difficult to discern the difference between the different types of antialiasing. GNOME’s dialog doesn’t let you select arbitrary text, or let you render text in-place so that you can quickly compare between different antialiasing styles and subpixel orderings. These settings, along with DPI, are unlike the rest of the settings in the font configuration dialog because they don’t apply immediately. They only affect newly started applications, and the dialog does nothing to alert you of this.

Do users really need to be able to select subpixel ordering from a dialog? There are very few LCD monitors that do not use an RGB subpixel ordering. The very few people who rotate their LCD monitors into portrait mode (including me, see my past article Misery with online reading of PDFs and the need for portrait monitors) would use VRGB. Why not just set RGB subpixel ordering if the user is using an LCD? VRGB if their display is rotated? Again, these are things GNOME could discover by querying X…

Lastly, do users need to change the fonts used by their UI in the first place? The majority of Windows and MacOS X users don’t deviate from the defaults at all—why would GNOME users be given a choice through this confusing dialog? GNOME instead should use the fontconfig aliases “Sans”, “Sans Serif”, and “Monospace” rather than letting users choose fonts. A fresh GNOME setup already uses these aliases as the defaults anyway.

Of the settings in the font configuration dialog users may actually want to set, whether to use antialiasing or not is the only one that sticks out to me as needing an option. I think that the dialog could be replaced with a simple, descriptive checkbox somewhere that read “Antialias text” that would toggle all the heuristics I’ve described above.

Yes, GNOME is limiting!

There’s been a lot of fallout from Linus’ latest criticism of the GNOME desktop, with which I complete agree. I feel as if I need to comment on some of the responses.

Carthik Sharma writes in Of Apples and Oranges, GNOME and KDE:

I dread having to find something, since it most definitely will be placed in some non-intuitive sub-menu.

KDE has no control over where applications decide to place themselves.

I like the way GNOME display fonts on the screen. I don’t want to have to change every little variable to get the perfect system.

GNOME pioneered use of fontconfig; in fact, lately, GNOME has been pioneering the use of many next-gen APIs and technologies (e.g. AIGLX, Beryl, etc). But Qt/KDE have also been using fontconfig for several years now—what’s different?

Interesting enough, there has been criticism about how GNOME handles fonts. Taking points from that article, GNOME’s font configuration is a mess:

  • What’s a “Terminal” font (it should be called “Monospace,” as it is in KDE, because this is how it’s also used throughout GNOME)?
  • What does “size” mean (apparently, it’s not what you think)?
  • Why do I care about the subpixel ordering of my fonts’ antialiasing?
  • Why would I need to set fonts at all (see my weblog entry The GNOME font dialog, why?)?

KDE is no different than GNOME in trying to provide “sensible” defaults, defaults that its developers have decided are intrinsic to a “perfect desktop.” But, what the developers have decided is the perfect desktop may not be your perfect desktop—and here lies the essence of Linus’ argument, and the difference with KDE and GNOME. With KDE, you may have an option to make a setup “perfect”; with GNOME, quite often the option won’t exist and you are limited to what the powers that be decided was perfect for them, not you. This is Linus’ argument: GNOME is limiting.

Sprint's EVDO Mobile Broadband on Ubuntu GNU/Linux

[inline:sprint-mobile-broadband-card.jpg]

So, you’ve gotten your shiny new EVDO datacard working under Linux (if not, see High-speed cellular wireless modems (e.g. EVDO, HSPDA) in Ubuntu GNU/Linux 6.10) and you want to now setup the actual Internet connection?

In this article I document how I setup Sprint’s Mobile Broadband service with ppp in Ubuntu GNU/Linux 6.10.

Pages

Subscribe to Samat Says RSS