Wordcount Widget!

Note the awesome wordcount widget I added to the right sidebar. This widget is awesome because it AUTOMATICALLY tracks the wordcount on my latest work-in-progress, no manual updating needed.

For those who are interested in the technical side of it, here's how it works:

1. My computer automatically backs up all my files to a remote server every night.
2. Since I use OpenOffice, the document in question is in .odt format. I discovered that a nice feature of this format is that the word count of the document is availabe in the raw document code (search for "meta:word-count").
3. The image you see is actually a PHP script on the same remote server. When viewed in a browser, the script extracts the wordcount directly from the document and generates the image on the fly.

Result:

Speed v. Safety

When programming, you have to walk a fine line between getting code out, and making code secure.

I'm actually not talking about general security issues, although there are unfortunate circumstances when you (as an employee) don't have the option of taking the time to make your code (or your predecessor's code) secure.

I'm talking about coding for things that should "never happen." I'm talking about coding for that particular sequence of actions you think no one will ever do, or that edge case that no one will ever hit, or even that thing you think can never happen.

I try to be reasonable with what I do, although I like to err on the side of caution. For example, here's a bit of PHP code:

<?php
header("Location: index.php");
?>

Theoretically, that is supposed to redirect the visitor to the index.php page...say, if they weren't authorized to be on the current page. I always assumed it always worked, no exceptions.

However, back in the mists of my early programming, some person, or webpage, or something suggested putting an "exit" statement afterwards, just in case it didn't. That way, if the person wasn't redirected to the proper page, the current page would just die. It's better than having an unauthorized person viewing the page.

<?php
header("Location: index.php");
exit;
?>


So I've always done that. Better safe than sorry. I found out the reason for doing so today: apparently, it's up to the web browser (or web crawler, etc.) whether or not it wants to obey the headers, including the "Location" one in the PHP code above. I knew that, I just never really made the connection between that fact and this situation. So, if a browser or crawler doesn't obey the header, the page will just die.

You learn something new each day. I'm glad I was already writing secure code (for that situation), even if I didn't know why...

Setting up GnuPG (GPG) for use with PHP

Step 1 (failed):

$ pecl install gnupg

downloading gnupg-1.3.1.tar ...
Starting to download gnupg-1.3.1.tar (-1 bytes)
.............done: 124,416 bytes
5 source files, building
running: phpize
Configuring for:
PHP Api Version: 20020918
Zend Module Api No: 20020429
Zend Extension Api No: 20050606
`phpize' failed

Step 2 (success). Some information drawn from http://www.php.net/manual/en/install.pecl.php, a basic tutorial on how to install PECL extensions.

$ cd /usr/lib64/php/extensions

(This is where my PHP extensions [files with .so extension] are stored)

$ pecl download gnupg
$ tar -zxvf gnupg-1.3.1.tgz
$ cd gnupg-1.3.1/
$ phpize
$ ./configure
$ make
$ make install

"gnupg.so" now appears in /usr/lib64/php/extensions
Now I need to install the extension in the php.ini file

$ whereis php.ini

/etc/php.ini

$ vi /etc/php.ini

Find the list of extensions in php.ini, in my case headed by "[extension section]". Add "extension=gnupg.so" to the end of the list, save and exit.
Now I need to restart apache so the extension takes effect.

$ apache2ctl graceful

Now do some PHP coding. Assumes you have GnuPG (gpg) installed, and have set up your key pair ("gpg --gen-key"). Some of these steps might be unnecessary, but after hours of fiddling around, I'm not about to walk through it again and find the essential ones.

/* Change this to your own path */
putenv("GNUPGHOME=/home/bch36/.gnupg/");

$encrypted_data = file_get_contents("encrypted.gpg");

$res = gnupg_init();

gnupg_seterrormode($res,GNUPG_ERROR_WARNING);

/* Change this to your own fingerprint. Find your fingerprint by running "gpg --fingerprint" from the commandline. Comment this out when everything works. */
print_r(gnupg_keyinfo($res,"ASDF1234QWER5678ZXCV9012ASDF3456QWER7890"));

/* Put your own fingerprint and passphrase here. Also, this function will fail unless you see Important Note #1 below */
gnupg_adddecryptkey($res, "ASDF1234QWER5678ZXCV9012ASDF3456QWER7890", "put your secret passphrase here");

/* You'll want to comment this out when everything is working */
echo gnupg_geterror($res);

/* This function will fail unless you see Important Note #2 below */
$plain = gnupg_decrypt($res, $encrypted_data);

Important Notes:
1. To get gnupg_keyinfo() to work, you'll need to let your webserver have some access to your keyring. Do the following (replace "www" with the group that your own webserver runs under):

> cd /home/bch36/.gnupg
> chown :www pubring.gpg trustdb.gpg
> chmod 660 pubring.gpg trustdb.gpg

2. To get gnupg_decrypt() to work, you'll need to grant more access. Note that the webserver will now have access to your secret key! However, if you don't do the following, the gnupg_decrypt() function will fail and you'll get the following warning when printing out gnupg_geterror(): "Warning: gnupg_adddecryptkey() [function.gnupg-adddecryptkey]: get_key failed in ..."

> chown :www secring.gpg
> chmod 660 secring.gpg

As a possible point of interest, I'm only doing decryption because I want a remote webpage to use Javascript to PGP encrypt data and send it to my PHP file, which can then decrypt it. I guess it's a workaround for not having SSL. I'll try to post an entry about the client-side next (Javascript PGP).