
Yes, this is not the most elaborate track I ever built, but for a Sunday, 7 am track, this will have to do.

Yes, this is not the most elaborate track I ever built, but for a Sunday, 7 am track, this will have to do.

Recently, two mails of a conspiracy theorist sneaked past my spam-filter. Pure flashback to the heyday of the good old Usenet kooks. Consider this quote:
The Jewish nazis also continued to send ‘messages’ and ‘feedback’ to me through the media and internet and through the EBL &emdash; Electronic Brain Link – whereby, among other things, they ‘invited’and sucked me in to directing my attention and using my amazing power on images in magazines, the internet, TV and other media
I mean, if that doesn’t trigger your kook-detector, nothing will.


I always knew Bill Watterson is a genius.
(I stumbled upon the strip while re-reading my C&H books. Picture from here.)
As mentioned before, I disabled xen before the etch->lenny upgrade. Now I’ve re-enabled xen, and the following bits may be of wider interest:
My server at the Hetzner hosting center has one static IP address and a small network that is routed towards that IP address. So my plan was to use this small network (88.198.160.176/28) for the virtual switch inside the xen Dom0 and connect all the domUs to it. I solved this the following way:
In /etc/network/interfaces I tell Debian to create the bridge and use br0 as the interface of the dom0 into that bridge:
auto br0
iface br0 inet static
pre-up brctl addbr br0
address 88.198.160.177
netmask 255.255.255.248
bridge_fd 0
bridge_hello 0
bridge_stp off
That way, the xen scripts themselves have little to do. The settings in /etc/xen/xend-config.sxp are:
(vif-script 'vif-bridge bridge=br0') (network-script network-route)
In the config-file for each individual domU, I just use something like
vif = [ 'ip=88.198.160.178,mac=00:16:3e:77:e2:79,bridge=br0' ]
but I’m not sure whether that’s actually needed at this point.
Concerning the domUs: The hints in the Debian Wiki were helpful, especially about changes to the console handling.
Just in case somebody was wondering why this blog was down over the weekend:
I finally bit the bullet and upgraded my server from Debian etch to Debian lenny. And while doing that ran into Bug #541371.
Otherwise the upgrade was pretty painless. But as timid (some might say sane) as I am, I disabled xen before the upgrade. Getting that up and running with a new kernel will be the next step. This is especially tricky as I do not have a remote console, just the Hetzner rescue system.
Oh, and as I’m no longer running a pre-historic wordpress, this blog might get a new design sooner than later.

CAcert has tried for some time to provide free X.509 certificates based on automatic checks and a web of trust. They never managed to get the root certificate included in the default installations of the major browsers. As I read it, they’ve given up on Mozilla for now.
Aaron forwarded me a link to a blog post by StartCom where they announce that their CA will be included in IE soon. As they are already recognized by Mozilla and Safari, their certs are pretty much as good as any other commercial x.509 cert for servers.
In that respect, they are not unique, you can buy commercial grade certs from various sources, the most popular being Thawte, Equifax, Usertrust, Comodo, and Verisign.
What makes StartCom special is the fact that they give away free certificates similar to what CAcert is doing. Their enrollment at http://www.startssl.com/ is pretty much straight forward and getting certificates (both by uploading CSRs or by letting them generate a key) is painless.
Furthermore, they impressed me by:
Recommended.
Bumped to top due to updates.
For my current project I look at a lot of X.509 certificates using Dan Sully’s Crypt::OpenSSL:X509 Perl module. I’m not using the version from CPAN, but his current codebase straight from his git repository.
While trying to store information about certs in a PostgreSQL DB which is set to UTF-8 strings, I encountered errors. Some debugging later I found that some of the certs had Umlauts in the subject field. The XS code from Crypt::OpenSSL:X509 wasn’t UTF-8 aware, causing automatic down-conversion to ISO-8859-1, which produced illegal byte sequence when parsed as UTF-8.
After some cursing and debugging I came up with this patch:
--- ../dsully-perl-crypt-openssl-x509/X509.xs 2009-03-06 22:22:44.000000000 +0100
+++ X509.xs 2009-08-17 14:46:00.000000000 +0200
@@ -73,6 +73,15 @@
return sv;
}
+static SV* sv_bio_utf8_on(BIO *bio) {
+
+ SV* sv;
+ sv = (SV *)BIO_get_callback_arg(bio);
+ SvUTF8_on(sv);
+ return sv;
+}
+
+
/*
static void sv_bio_error(BIO *bio) {
@@ -293,8 +302,10 @@
name = X509_get_issuer_name(x509);
}
+ /* this need not be pure ascii, try to get a native perl character string with utf8 */
+ sv_bio_utf8_on(bio);
/* this is prefered over X509_NAME_oneline() */
- X509_NAME_print_ex(bio, name, 0, XN_FLAG_SEP_CPLUS_SPC);
+ X509_NAME_print_ex(bio, name, 0, (XN_FLAG_SEP_CPLUS_SPC | ASN1_STRFLGS_UTF8_CONVERT) & ~ASN1_STRFLGS_ESC_MSB);
} else if (ix == 3) {
@@ -799,7 +810,8 @@
n = OBJ_nid2sn(nid);
}
BIO_printf(bio, "%s=", n);
- ASN1_STRING_print(bio, X509_NAME_ENTRY_get_data(name_entry));
+ sv_bio_utf8_on(bio);
+ ASN1_STRING_print_ex(bio, X509_NAME_ENTRY_get_data(name_entry),ASN1_STRFLGS_UTF8_CONVERT & ~ASN1_STRFLGS_ESC_MSB);
RETVAL = sv_bio_final(bio);
OUTPUT:
Basically, this just tells the openssl library to output UTF-8 and the perl core that the new strings are encoded in UTF-8.
This might be overkill in the cases where it’s not actually needed, but it should do no harm.
Update: My patch is now in the git repository.
Update2: Life is not that easy. Looking at more X.509 certs in the wild shows that openssl does not check whether it returns a valid UTF8 string. So stay tuned for additional patches in Dan’s git repository.
Update3: My patches are now integrated in the git version.