29 June 2008

n800 maemo updates

I got a Nokia n800 Internet tablet a few months ago and installed the Maemo os2008 software platform. I put the n800 in red pill mode to install some packages, and I just left it that way and forgot all about red/blue pill mode.

It didn't take long for me to find that updates just didn't work, but I never put the two things (red pill mode and broken updates) together. Looks like this is a well-known problem (see the bottom of the red pill mode wiki page linked above).

So if you put your n800 in red pill mode and updates don't work (mine complained that it needed to resolve libglade dependencies: it seemed to want to update to a version which was already installed), put it back in blue pill mode and try running updates. That worked for me.

22 June 2008

mcrypt randomness in PHP

The other day I was trying to debug a PHP program which was being really slow. I'm not bright enough to use proper debugging tools (like xdebug), so I just sprinkled in a bucketload of error_log() calls until I figured out what was gumming up the works.

It turned out to be an mcrypt_create_iv() call. Sometimes that call would run in a fraction of a second, and sometimes it would take over a minute, with no discernible pattern. I had pretty much done a copy-and-paste from the mcrypt_module_open() manual page, which shows using the MCRYPT_DEV_RANDOM constant as the second argument to mcrypt_create_iv(). It finally occurred to me to try using the MCRYPT_DEV_URANDOM constant (note the "U"), instead, and the encryptions immediately became consistently fast.

This was happening on a VMWare ESX guest running RHEL4. A Web search or two found a good comparison of /dev/random v. /dev/urandom, and my problem turned out to be a good illustration of /dev/random blocking the caller until sufficient entropy is attained.

21 June 2008

HTML form attack

The other day I came across a post about the HTML form attack.

I don't think I'd seen this before, and I'm not well versed in JavaScript attacks (authors of the planet-websecurity.org blogs would probably point, laugh, and yell "NOOB!"). But when I sort of figured out what it was talking about, it occurred to me that a form on a page which is vulnerable to cross-site scripting could be made to POST to an arbitrary location. Try the following in a JavaScript-enabled browser, and see where it ends up taking you when you click the submit button:

<form id="gakkk" action="/good.html">
<input type="submit" />
<script type="text/javascript">
// <![CDATA[
document.getElementById('gakkk').action = '/bad.html';
// ]]>

20 June 2008

GPG wallet in cygwin

The other day it occurred to me try my password wallet in cygwin. The wallet requires dialog, but cygwin doesn't seem to have a dialog package. So I figured I'd try building it.

dialog requires ncurses, which meant that I needed to install the ncurses-devel cygwin package (using the cygwin setup tool). Then I downloaded the dialog source and did configure && make && make install, and that "just worked" to get dialog in cygwin. And then the wallet "just worked," too.

So if you're running Windows and want to try the password wallet, install cygwin and give a wallet a try.

19 June 2008


(I'm practicing for an "Unreadable blog post title" contest.)

Here are a few hints on how to use SSL certificates when connecting to MySQL from a PHP program using the AdoDB database abstraction layer. (You may want to see my previous post on setting up SSL certificates for MySQL connections.)

The trick is to use a DSN in the NewADOConnection() call (rather than authenticating with a Connect() call) and to use the mysqli driver (looks like the mysql driver won't work for this). The DSN syntax allows you to supply client flags, and there's a mysqli flag for using SSL certificates.

After creating a CA certificate (we'll say it's at /path/to/ca-cert.pem), make sure that the following item is in the [client] stanza of /etc/my.cnf or the connecting user's ~/.my.cnf on the client host:


Then try the following PHP program:

// these are part of the AdoDB library
require '/path/to/adodb-exceptions.inc.php';
require '/path/to/adodb.inc.php';

* I got the '2048' from running
* printf( "%d\n", MYSQLI_CLIENT_SSL )
* in a PHP program (w/ the mysqli extention installed)
$dsn = 'mysqli://ssluser:sslpass@dbhost/test?clientflags=2048';

$dbh = NewADOConnection($dsn);

$sql = "show status like 'ssl_cipher'";
$res =& $dbh->Execute($sql);
print_r( $res->fields );

This should generate output similar to like this:

[0] => Ssl_cipher
[Variable_name] => Ssl_cipher
[1] => DHE-RSA-AES256-SHA
[Value] => DHE-RSA-AES256-SHA

17 June 2008

SSL in MySQL connections

Last week I wanted to figure out how to use SSL certificates in MySQL connections. This is well-documented on the MySQL Web site, but here are a few wrinkles I experienced while figuring out how to get this working (this was with MySQL5 on CentOS5 and RHEL5).

After creating the certificate authority (CA) certificate/keyfile pair, you can specify them in the mysqld section of /etc/my.cnf:

When making certificates for a client connecting locally (e.g., ssluser@localhost), it's important to supply localhost as the "common name" when prompted by openssl. (Yes, it's probably pretty silly to use SSL for a connection over the loopback interface, but you might be in this situation if you were testing.)

If you want to specify the CA (whose signature must appear in client certificates) when setting up a MySQL user (as you might when using the require x509 syntax), the fields should be separated by backslashes ('/'): grant usage on *.* to ssluser@localhost require issuer '/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd/CN=www.example.com/emailAddress=webmaster@example.com';
The following command will more-or-less correctly format the issuer for the grant statement:

openssl x509 -text -in /path/to/ca-cert.pem | grep Issuer \
| cut -d':' -f2 | sed -e 's/, /\//g'

Using issuer and subject items imply x509, and it's an error to try using x509 and issuer.

Depending on the require clause in the grant statement, you can use one or more of the following to connect to the SSL-enabled server:

  1. mysql -u ssluser -p

  2. mysql -u ssluser --ssl-ca=ca-cert.pem -p

  3. mysql -u ssluser --ssl-ca=ca-cert.pem --ssl-cert=client-cert.pem --ssl-key=client-key.pem -p

If you use require none or omit the require clause, you can use any of the three connection commands. If you use require ssl, you can use #2 or #3. And if you use require x509, you have to use #3 (note that #3 includes the --ssl-ca option). After connecting, type status (or just \s) and make sure that the SSL item says something encryptiony (mine says Cipher in use is DHE-RSA-AES256-SHA).

Unless client certificates are really necessary (extra client-level authentication), it's probably adequate just to use require ssl and to have the client provide the CA certificate (this appears to provide as high a level of encryption as the client certificate does). But note that you still need to generate the server certificate and key, even if you're not using client certificates.

15 June 2008

MIME-decoding email attachments

Occasionally a friend will forward a message to my gmail account, and the forwarded message ends up as a plain-text attachment in the message I receive. If the original message had an attachment, that attachment appears as a MIME-encoded section of the attachment.

If this happens to you, you could try the following. Save the attachment as a text file, and open that file in a text editor. Delete all the lines except the lines which represent the encoded attachment (don't keep the attachment headers, just the lines of text which are 76 characters wide [the last line may be shorter--keep that one, too]). Don't forget to get rid of the lines after the attachment. Save the file as encoded.txt.

Save the following to an executable file called mime_decode somewhere in your $PATH:

#!/usr/bin/perl -w

use strict;
use diagnostics;

use Carp;
use MIME::Base64;

my $usage = "$0 infile outfile";
if ( @ARGV != 2 ) {
die "usage: $usage\n";
my ( $infile, $outfile ) = @ARGV;

open my $fh, '<', $infile or croak "cannot read $infile";
my $encoded = join '', <$fh>;
close $fh;

my $decoded = decode_base64($encoded);
open $fh, '>', $outfile or croak "cannot write $outfile";
print {$fh} $decoded;
close $fh;

Then run the following command:

mime_decode encoded.txt decoded

decoded should be the original attachment.

If you know of a standard utility which does this (especially if it doesn't require the user to prune the email message), please leave a comment.

13 June 2008


As a big Transformers fan and someone who, well, goes to the bathroom, I thought this was pretty cool.

01 June 2008

Fallen Tree

There was a ferocious wind-and-rain storm here a week ago, and it knocked over some trees. I took some pictures of one of the more impressive casualties. I think it was an elm tree, and (judging by the rings) it appears to have been around forty years old. They cut it up to cart it off, and they made a cut just above the roots. It was probably around two feet in diameter at the base.

Here are a couple of the pictures...

another ring detail

gnarled roots

Burning Universal Studios

A couple of years ago I visited L.A. with friends, and we checked out Universal Studios. We took the tour, which included the cheesy-but-fun King Kong attraction.

That part of the tour was destroyed by fire this morning. The same fire damaged the town hall clocktower from the Back to the Future set, and damaged over 40,000 reels of film (fortunately, there are duplicates in another location--someone was awake during the "Make Backups" lecture at film school).

Tourist attractions have had a hard time of it lately.