I you have read my previous post, GPG Best Practices, you will know that I am a fan of setting expiration dates on my GPG keys.
This has not always been the case. As with many computer users I tend towards the lazy, and if I can keep from having to re-learn a password by never changing it, then I have been guilty of doing so.
Recently, however, I have decided that this is not the best thing to do when it comes to computer security. So while restoring my computer this weekend after a rebuild of the OS to get rid of some cruft that had built up, I decided I needed to add expiration dates to all of my GPG keys.
Now I had already established one for my work e-mail at the time I created the key, but now I needed to go back and add ones to my personal keys. After reading the man page on GPG, it looked pretty easy. Just go into edit mode for the key I wanted to change, the add an expiration date. Simple enough, right? Wrong.
Turns out the what I wanted to do was feasible, just not readily apparent. I didn’t just want to set a date relative to the current date in day, months, weeks, or years. What I wanted to do was use a specific date.
Well, after some diligent searching on Google, I found the following in a post on the gnupg-users list:
>>Is it possible to set an explicit date (e.g. 31 Dec) rather than a >>duration? I suppose I could compute the number of days, but that’s
>>annoying.
Problem solved, mission accomplished.
Like many people who have some concerns over security on the Internet, I have started to use digital signatures for all of my mail sent from my regular e-mail client on my Mac.
While there are several avenues for this, I chose to use GPG. While I know that this means jumping through a couple of extra hoops in configuring my mail client, I decided that it was worth it, because unlike the Thawte Freemail certs, using GPG on my computer also means that I can encrypt files in addition to my mail messages, should I choose to do so.
I am wondering what the thoughts are on best practices when it comes to using GPG.
Here are a couple that I have come up with (learned through hard experience):
1. Backup your keys.
I cannot stress this strongly enough. If for some reason you have a catostrophic computer failure, you will need those backups in order to decrypt your e-mail once you restore your data backup. (You do back your data up, right?)
And when you make those backups, do not rely on just a digital backup. Backup both your public and secret keys in an ASCII-armor file and print the darned thing out. Digital backups are subject to data rot and any number of other technological snafu’s, but I have printed material that is perfectly readable after more than 20 years.
2. Make a revocation certificate.
The GPG mini-howto gives a couple of excellent reasons for doing this:
For instance: the secret key has been stolen or became available to the wrong people, the UID has been changed, the key is not large enough anymore, etc.
Just remember that revoking a key is not reversible.
3. Set an expiration date for your keys.
Just like changing passwords, you should regularly change your GPG keys. Don’t worry about losing track of the data that was encrypted with a key that has expired. You’ll still be able to open that data, it just means that someone won’t be able to encrypt with the old key unless they ignore the warnings about it being expired.
What this also means is that you should hang on to the expired keys, since you might need them to access some older encrypted files. (See best practice number 1)
4. Add commentary to your keys.
If you are like most heavy computer users, you have more than one e-mail address. And if you create a GPG key for each one of those, it would help to keep things orderly if you commented on the individual keys.
For example, the key I use for my work e-mail has a comment of:
Work Address
So, do you have anymore best practices?
Sad news came to me today by way of another member of the Yahoo! Group I am a member of. For those of you who may not know this, I lost my wife, Patricia Grace Fore, on August 16, 2004.
After Pattie died I joined a Yahoo! support group for young widows. They are a great group of people, whose numbers unfortunately grow way too fast.
One of the members of the group, Dusty, was a great guy who excelled in being tremendously optimistic about his life, even in the face of his own loss and his own health problems. He never failed to make us feel better about the situation we were in, even though his own was ofttimes worse than our own.
Dusty passed away last Sunday from his ongoing health problems.
There just aren’t words enough to express how sad this is and how much he will be missed. You are gone but not forgotten my friend, and you gave help and comfort to many of us along the way with your friendship and understanding.
Another member of the group wrote the following poem for Dusty some time back:
Grief is Like a River
“My grief is like a river I have to let it flow But I determine where the banks will go Some days the current takes me into waves of Guilt and Pain But there are quiet pools Where I can rest again I crash on the rocks of anger My faith seems faint indeed But there are other swimmers in here Who know what I need Loving arms around me. When the waters are to swift And I just seem to drift Someone kind like Dusty Listens to my broken Heart beat. Grief’s River is a process of Relinquishing the past By swimming into the Channel of Hope I’ll reach the shore
At last.”
— SF1
As many of us have said, you were our special angel, Dusty. Wind to thy wings, my brother and friend.
When trying to sort my cthub XML file recently I found out that my code from the post on sorting the role listing had stopped working.
Turns out that there was an error introduced into the format of this file when upgrading from Contribute 3.11.
As you are no doubt aware, when at least one admin upgrades to Contribute 4 or Contribute CS3 (aka 4.1) all the admins have to since there are upgrades made to the XML files that control the site. Well it appears that this upgrade makes the cthub file non-valid XML.
Take a look at this file and look for the tag font_use_css inside the group_list_item child node of the group_list node. In a copy of the cthub file that was upgraded you will find that this standalone tag is missing the appropriate closing slash. If you compare this against a copy of the cthub file from before the upgrade, assuming you made a backup, you will find that the tag is properly closed.
Since this file is the master file with all of the role information for the site, I wonder if this XML error is causing unknown instability in the system somewhere.
While this is an easy fix, I will be posting some code that you can run to fix this, since editing a file like this by hand can be a real pain.
While changing some things on my computer setup today I decided to change the name of my harddrive and computer to match my local DNS entry.
Having done this many times before I knew that there would be certain applications that would be looking for an absolute path that would have issues, such as Dreamweaver sites and the root folder locations for them.
Adobe Contribute (formerly Macromedia Contribute) has the same problem with the stored sites that you have setup prior to the name change.
Here is how to fix Contribute after changing the harddrive name:
- Open up the Contribute preferences file located in /Users/USERNAME/Library/Preferences/
(in my case the filename was Contribute 4.1 Preferences, this will be different for other versions) in your favorite text editor.
- Start searching at the top of the file for each instance of the old harddrive name.
- Replace each instance with the new harddrive name.
- Save and close the file.
Now the next time you start Contribute, you won’t get the any error messages related to having missing site files.
Oh, and don’t forget to backup the file first. You do back up your data right? 