Five minute guide to Windows GnuPG email encryption with Thunderbird's Enigmail

I decided to go beyond GPGShell for using GnuPG for email. While GPGShell is excellent for There's a wonderful extension called Enigmail for Mozilla Thunderbird that makes it very easy to use GnuPG to encrypt and decrypt your email; however, I spent a little while scratching my head configuring it to be the way I wanted. Here's what I ended up doing:

1) Install and configure GnuPG (latest version 1.4.2)

The install went smoothly, but I wanted my keyrings to be somewhere other than the default of C:\GnuPG. There are supposed to be three ways to relocate them:

• Pass the --homedir switch to gpg on each execution (a pain if you are using multiple GnuPG clients);
• Use regedit to set the HKLM\Software\GNU\GNUPG key's HomeDir string value with the path, but this did not work for me (I tried specifying it both with forward slashes and backslashes but it never changed the setting from the default);
• Set the GNUPGHOME environment variable. This worked great for me and sets the location for any execution of GnuPG (either from Enigmail, GPGShell, or any other client).

2) Install and configure Enigmail

Be sure to remove any old versions first. The only option I really had to change was related to the multiple identities I have set up. You have to enable Enigmail for each identity, and after doing so, you get prompted with the Per-Recipient Rules Editor asking how to sign/encrypt for each recipient of your email. I just wanted it to respect what I specified in the OpenPGP button when composing mail instead. The secret is to add a rule to this dialog with the recipient containing '@' and no PGP key specified that makes it permitted to sign, encrypt, and use PGP/MIME.


After doing this, Enigmail will respect the sign/encrypt settings you put for an individual email message in the compose window. Make sure this rule is the last rule.

3) Upgrade your signing key

If you use PGP/MIME to encrypt email and have generated your private key using the GnuPG default DSA signing key and El-Gamal encryption key, you will quickly run into an error from gpg stating that you can't use SHA512 (or any hash algorithm better than SHA1) with PGP/MIME. This is because the DSA signing key only supports SHA1. Since SHA1 has been broken, you may wish as I did to use a better signing algorithm anyway. I found this excellent article walking you through the steps on how to do this. To paraphrase them and get to the meat of it, using the GnuPG command line, you have to add a new signing key:

To generate a new subkey begin by editing your key (–edit-key ‘name’), then choose addkey, and finally choose RSA (sign only). That’s it; now you can use the newer SHAs.

That's it--you should have a pretty smooth encryption experience.

Adventures in building Subversion 1.2.1 on Mandriva Linux

I wanted to install Subversion on my Mandriva Linux 2005 LE distribution, but the distro has only version 1.1.4 packaged and I wanted the current version (1.2.1). I decided to build it from the source tarball.

I decided to use Apache instead of svnserve. I installed the following packages from the distro:

• apache2


• apache2-devel (I'm not sure if this is explicitly needed but I installed it anyway)


• apache2-mod_dav

When I first ran Subversion's configure script, it skipped building mod_dav_svn, the module needed for Subversion to work via Apache. To get it to include mod_dav_svn, I did the following:

./configure --with-apxs=/usr/sbin/apxs2
make
make install (after issuing su)

After this, Apache wouldn't start--it was reporting an error about some missing symbols I believe (I don't recall the exact error message). The problem was that the Apache module mod_dav.so has to be loaded before mod_dav_svn.so and mod_authz_svn.so modules. I edited /etc/httpd/conf/httpd2.conf and added the following line just above the two LoadModule commands the Subversion install inserted to load mod_dav_svn.so and mod_authz_svn.so:

LoadModule dav_module modules/mod_dav.so

Then, I needed a Location section in httpd2.conf for Subversion. I set up basic authentication with a specific user list. I also wanted my Subversion virtual root to be /svn (i.e. http://server/svn), and to have all repositories I created to follow this URL (e.g. http://server/svn/repo1, http://server/svn/repo2). The section, placed at the very bottom of httpd2.conf, looks like the following:

<Location /svn>
  DAV svn
  SVNParentPath /home/svn
  Require valid-user
  AuthType Basic
  AuthName "Subversion repositories"
  AuthUserFile /home/svnpasswd
</Location>

That was it for httpd2.conf. Then I needed to add a user to the authorized user file. I did this with htpasswd:

htpasswd /home/svnpasswd myusername

Next I needed to fix the permissions on the repository root I chose, /home/svn. The way I got this to work was to make apache the owner and users the group, and give both read/write access. Note the -R for recursive to apply to the repository subfolders I created:

chown -R /home/svn apache
chgrp -R /home/svn users
chmod -R +rw /home/svn

Lastly, I needed to configure msec so it doesn't come along and wipe out the permissions and ownership I changed on /home/svn. I edited /etc/security/msec/perm.local and added the following lines:

/home/svn current 770
/home/svn* current 770

Happy Subversioning!

Remote DTC access and the Windows XP firewall

I recently had to get my test classes to be able to create distributed
component services transactions from my Windows XP development
machine. Doing this required a bit of configuration both on my machine
and on the Windows 2003 server I was transacting.

In the XP firewall:

1. Add TCP port 135 to the Windows Firewall exceptions list.
2. Add Msdtc.exe to the Windows Firewall exceptions list on all computers involved in Microsoft Distributed Transaction Coordinator (MS DTC) transactions.
   

Enabled network DTC access on the Windows 2003 server (from
http://support.microsoft.com/default.aspx?scid=kb;en-us;817064):

1. Click Start, point to Control Panel, and then click Add or Remove Programs.
2. Click Add/Remove Windows Components.
3. Select Application Server, and then click Details.
4. Select Enable network DTC access, and then click OK.
5. Click Next.
6. Click Finish.
7. Stop and then restart the Distributed Transaction Coordinator service.
8. Stop and then restart Microsoft SQL Server and the other resource manager services that participate in the distributed transaction, such as Microsoft Message Queuing.

Further, in the Component Services snap-in on the Windows 2003 server:

1. Right-click the appropriate computer node and select properties.
2. On the MSDTC tab, click Security Configuration button.
3. In addition to the Network DTC Access being checked, check Network Transactions.
4. Restart MSDTC (and SQL Server, if SQL Server is being transacted).