1. Backup the DB ($ mysqldump -p dbname | gzip &gt:~/backups/$(date -iso-8806)-dbname.sql.gz).
2. Backup the existing directory (# cp -a current-directory directory-outside-of-the-web-space).
3. Extract the new version on top of the old ($ tar -zxf ~/wordpress-version.tar.gz).
4. Delete the wp-config-sample.php file.
5. Fix group ownerships of wp-content/ and sub-directories.
6. Visit the admin interface.
7. Fix problems, if there are any.

This time, there was nothing to do for the last two steps. It was all over in just a couple of minutes. Simple as pie.

HowManyOfMe.com

There are people with my name in the U.S.A. How many have your name?

There are only 19 of Monty Peterson in the U.S.

We’ve been getting movies and TV shows from Netflix for over a year. It’s been a great experience for us. We have the 3 discs at once plan, which lets us hang onto some TV series disc for a few days (a couple of weeks) and still keep a couple of movies going back and forth. It’s also possible for us to watch up to 6 different movies in one week, as their turn around time is so fast, it (almost always) only takes 2 days from when I put a disc in the mail until the next one arrives.

Netflix also allows their customers to stream movies and TV shows on their computers, using the Roku player, the LG BD370 Blu-ray player/Netflix streaming device, plus many more. Netflix recently announced that they would be releasing a version for streaming on the Sony PlayStation 3 (a.k.a. PS3).

I’ve added about 20 films to my Instant Streaming Queue in the time I’ve written this article. I think I’ll go watch something.

I got an email from Netflix the other day, announcing that the PS3 disc is now available. It’s free, I simply had to click a couple of links and they sent it out to me. That disc arrived in the mail earlier today. We popped it in, waited for the PS3 to say that it was ready for us to “watch” that disc, and a moment later, we saw cover art for movies and TV shows that are in our Streaming Queue. I selected Season 1 of Quantum Leap and started watching episode 4 (episodes 1-3 are only available on disc). It took about 35-40 seconds for the show to start playing. The playback was flawless. Zero audio or video glitches (I do have a solid 7Mbps DSL line)..

That’s enough! I’ve had it; I’m going to prevent this from bothering me again.

Well, the right way to fix this is to grab a clue-bat and use it on the Maildrop developer(s) who decided that hardcoding a 50 MB log file size limit into Maildrop was a good idea, until they change their mind(s). Seriously, though, I’m going to send them a patch for this lame duck.

In the meantime, I’ve written rotate-user-maildrop-logs, a shell script to place into your /etc/cron.daily/ (or similar) directory. I am releasing this under the terms of the GNU General Public License, version 3 (a.k.a. GPLv3).

I really like Maildrop. It’s great for me, but it’s not for everyone. For example, my wife isn’t going to sit down and use vi (or any other text editor) to maintain her very own ~/.mailfilter file. For this reason, I will be switching to Sieve in the near future, using the Cyrus IMAP server instead of Dovecot, which I’ve been very happy with.

Is that the time? OK, maybe I’ll have to write that patch for Maildrop on Saturday.

Also, system requirements were announced today.

This time, I decided to see if I could simplify the process a little bit. Instead of reassembling the content by moving the previous version out of the way and then cherry=picking the right files and directories to copy into a fresh extract of the new release, I decided to make a backup copy of he current directory (and the DB) and then copy the extracted files of the new release over the top of the existing install. In this case, there were no DB changes to process, so it didn’t even ask me to “Upgrade the Database.” In fact, after the copy command was done, that was it.

I like it simple.

Still, I need to sit down and work out just how to reorganize the layout of a few things, since there are features that now better support much of what I want to do to better secure and simplify the running of my blog. Perhaps a project for this weekend?

This year, I’m not doing any presentation. I have some ideas for next year.

I will be running the keysigning party on Friday, October 9 at 7:15pm at the conference. I’m stepping into doing this a bit last minute, so we’re going to provide some additional info and the instructions for the keysigning party on the UTOSC website should be updated very soon.

To participate, just show up. If you want help generating a key pair and getting started, there will be several people there who can assist you, just be sure to bring your own notebook computer. If you have keys, please, email me your full key ID (not a short or medium) at keysigning@openbrainstem.net. It is a good idea to digitally sign that email. If you have multiple keys, include them all. I actually have three separate keys these days and 2 of them have multiple IDs associated with them.

(and PGP) allow us to digitally sign messages (usually email, but can be used with other communications systems, too), code and other documents. It also let’s us encrypt files, emails and just about anything else. This is an extremely important technology for a lot of reasons, some of which I’ve discussed in past articles on this blog (and others). Defending our privacy and ensuring the integrity of our personal, family and business communications is vital. We sign each other’s keys to build a “web of trust.” This is the critical step that makes the whole thing usable.

If you have never used PGP or GPG (a.k.a. GnuPG, Gnu Privacy Guard) before, visit the GnuPG website for a basic description of how to generate your key pair.

If you have never participated in a keysigning party, check out the Keysigning Party HOWTO and/or [ http://keysigning.org/ ].

Immediately following the Utah Open Source Conference 2007 keysigning party, I wrote a simple script to help help you sign-lots-o-keys. You can download the script from [ http://www.openbrainstem.net/download/sign-lots-o-keys ]. If I have time before the keyparty in just two days, I have some little updates that I would like to implement in that script. But don’t hold your breath. Perhaps there will be time at the conference on Saturday?

So, please, plan on joining us on Friday. These are always good fun.

The reason that it took an hour was that I was forced to upgrade several plugins and fix a couple of configurations. No big deal. It went pretty smoothly. Here are the basic steps that I go through:

1. Backup the DB
2. Move he current install out of the way
3. Extract the new code base
4. Copy the wp-config.php file to the new code directory

So, for example, I will run commands like these:

$ mysqldump -p dbname | gzip -9 >~/backups/dbname.sql.gz
$ mv web-server-vhost-dir/docroot/wordpress-blog-dir/ web-server-vhost-dir/
$ cd web-server-vhost-dir/docroot/
$ tar -zxf ~/wordpress-version.tar.gz
$ cp web-server-vhost-dir/wordpress-blog-dir/wp-config.php wordpress/
$ mv wordpress/ wordpress-blog-dir

Obviously, you need to replace the italic parts above with filenames and directories that match your setup. Perhaps you structure your website differently and the WordPress code will be in the root of your webspace.

After the new code is in place with the wp-config.php file copied in:

1. Hit the admin page in a web browser
2. Click the “Update Database” button
3. Test
4. Fix plugins, theme, caching, etc. (mostly file and directory owners/groups and permissions)

If there’s a problem, simply move the new code out of the way (or delete it, if you prefer) and copy or move the old one back into place. If the DB update process was run, you will have to restore your database to its previous state. This is easily accomplished with a single mysql command::

$ zcat ~/backups/year-month-day-dbname.sql.gz | mysql -p dbname

You’ll be so glad that you had that backup file.

Of course, it’s very important to have good, strong password security practices. If you have poor passwords, none of this will matter, as you’ve probably already been compromised whether you know it or not. This means that all users have to have strong passwords. Techniques for helping users to create and use strong passwords are beyond the scope of this article, but I will write about these things in the near future.

Here’s the configuration that I put into place. I’m showing this as the the iptables commands that you would run on the command line, adapt to however you persist your Netfilter configuration. Also note that these lines should replace anything that you now have in there for SSH. I’m also including the additional ESTABLISHED,RELATED rule here for completeness:

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -i $OUTSIDE_INTERFACE -p tcp --sport $UNPRIV_PORTS --dport 22 -m state --state NEW -m recent --update --seconds 10 -j REJECT --reject-with icmp-host-prohibited
# iptables -A INPUT -i $OUTSIDE_INTERFACE -p tcp --sport $UNPRIV_PORTS --dport 22 -m state --state NEW -m recent --set -j ACCEPT

These three rules mean:

1. Accept traffic for “conversations” that are already in progress. This rule works for traffic in both directions and will handle everything in the ongoing connection.
2. If an IP packet matches these criterion:
   1. “-A INPUT -i $OUTSIDE_INTERFACE” — coming in on the Internet connetion (I create a variable with the value “eth0” or whatever it is and use that in my firewalling scripts);
   2. “-p tcp” — carry TCP (for Layer 4) in the IP packet payload;
   3. “--sport $UNPRIV_PORTS” — coming from an unprivileged TCP port (legitmate clients should only come from source ports 1024 through 65535, inclusive);
   5. “--dport 22 — destined for TCP port 22;
   6. “-m state --state” — the state module doesn’t have a record of this packet as being part of an existing connection;;
   7. “-m recent --update --seconds 10” — the update module has a record of another connection attempt matching this one within the past 10 seconds.

   Take these actions:

   1. “-j REJECT” — throw the packet away;
   2. “--reject-with icmp-host-prohibited” — return an ICMP host-prohibited response to the client who tried to initiate this connection.
3. The last rule is essentially the same as the second, except for:
   1. “-m recent --set” — make a note of the time that this connection attempt occurs at;
   2. “-j ACCEPT” — if all criterion match, accept the packet (which will stop further rule processing here, BTW).

Basically, what we’re trying to do here is to limit the number of failed connection attempts that are allowed.

Let’s say that human being tries to connect via ssh lamont.example.com and they don’t have an account or the mis-type their password several times to the point where sshd cuts off the connection, so they re-run their ssh command to try again. It will probably work and let them in, as it probably took them longer than 10 seconds from the first packet of the first TCP connection until the first packet of the next TCP connection.

However, the cracker-bot-nets don’t work like humans. They automate the process of trying to connect as fast as they can, so they will try only 1 or maybe as many as 3 or 4 passwords before closing the TCP connection and starting another. Since they don’t have to be as slow as people, they’ll usually be coming back again in under the 10 seconds. Most of them actually try to establish multiple connections (2-20ish at a time) in order to try more passwords.

Once the crack-bot starts seeing TCP connection failures, they usually skip your IP and go on to try and find softer targets. If they can’t connect to SSH, then why bother wasting time trying.

After setting up this configuration and letting it run for a week, I can report that it works marvelously. I’m getting under 10 break-in attempts per day, now. If you’re going to have SSH visible to the world (and why shouldn’t you?), then I would recommend adopting these Netfilter rules in your firewall configuration.

First, when I was updating my wife’s blog, I got all in a hurry and forgot to make a backup of the database first. Then, when I connected to the wp-admin/upgrade.php script and clicked on the Upgrade WordPress button, all hell broke lose. I had DB errors left and sideways (thankfully, not quite right, though). At that moment, I realized that, “I could really use that DB backup right about now.” Well, I didn’t have it, so I tried the export function from the admin interface and that worked. At least I had her posts (there was a brand new one, too, which wasn’t in the most recent backup file that I did have).

The fix was pretty easy, though. The main problem was that there were several changes that required creating new tables in the DB (MySQL) and dropping others, but because the DB user that WordPress uses doesn’t just have full access to the database, these statements failed and prevented others from succeeding, too. For security reasons, I use GRANT statements for the tables that the app needs, which keeps it from accessing other tables in the same DB (there’s one database per user), which are for other apps. However, trying to run the wp-admin/upgrade.php script again was a no-go, as it thought the DB was fully up to date. A quick glance at the code in the wp-admin/upgrade.php script showed that this decision was based on the value in the db_version option.

I connected using the mysql command line client (over an ssh connection) and ran a couple of queries against one of the other DBs which had the same (older) version of WordPress. Once I had found the correct old value for the db_version option, I ran a simple UPDATE query (the italics indicate information that may differ on your databases):

mysql> UPDATE dbname.wp_options SET option_value='5183' WHERE option_name='db_version';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

I then re-loaded the wp-admin/upgrade.php script in my browser, which now thought that the database was out of date. So far, so good. But, before trying the upgrade again, I also added a new GRANT for the WordPress user for that DB, allowing them to run CREATE statements against that user’s database:

mysql> GRANT CREATE ON database.* TO 'wp_user'@'localhost';
Query OK, 0 rows affected (0.00 sec)

This time, there were far fewer errors. It was able to all the CREATE TABLE statements. However, as there were no GRANTs to permit the WordPress database user to access the new tables, other operations failed. A quick look allowed me to pick out which tables I needed to issue GRANT statements for:

mysql> SHOW GRANTS FOR 'wp_user'@'localhost';
+------------------------------------------------------------------------------------------------------------------+
| Grants for wp_user@localhost                                                                                   |
+------------------------------------------------------------------------------------------------------------------+
... snip ...
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_comments` TO 'wp_user'@'localhost'                 |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_categories` TO 'wp_user'@'localhost'               |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_postmeta` TO 'wp_user'@'localhost'                 |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_usermeta` TO 'wp_user'@'localhost'                 |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_posts` TO 'wp_user'@'localhost'                    |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_linkcategories` TO 'wp_user'@'localhost'           |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_options` TO 'wp_user'@'localhost'                  |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_post2cat` TO 'wp_user'@'localhost'                 |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_links` TO 'wp_user'@'localhost'                    |
| GRANT SELECT, INSERT, UPDATE, DELETE, INDEX ON `dbname`.`wp_users` TO 'wp_user'@'localhost'                    |
+------------------------------------------------------------------------------------------------------------------+
12 rows in set (0.00 sec)

mysql> SHOW TABLES IN dbname;
+-----------------------+
| Tables_in_dbname      |
+-----------------------+
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
10 rows in set (0.00 sec)

Comparing those two lists showed that I needed to run a few GRANT statements:

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER ON dbname.wp_term_relationships TO 'wp_user'@'localhost';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER ON dbname.wp_terrm_taxonomy TO 'wp_user'@'localhost';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER ON dbname.wp_terms TO 'wp_user'@'localhost';
Query OK, 0 rows affected (0.01 sec)

I then reset the db_version option, re-loaded the wp-admin/upgrade.php script in my browser and clicked the Upgrade WordPress button, again. This time, it worked perfectly. The database for my wife’s blog was fully repaired and upgraded for WordPress 2.3.1.

Now, I want to stress here that this would have gone a lot more smoothly, not to mention safely if I had only slowed down and made that backup of the her database before I started messing around with it. It’s very easy to do just that:

$ mysqldump -p dbname > ~/backup/$(date --iso-8601)-dbname.sql

Note, that this precise command line assumes that you are running from a user account who has a database account in MySQL with the same name as the username and that this user has access to the database in question. Adjust your usage appropriately. Also, if your server is fairly busy, you might want to use the mysqldumpslow command instead of the mysqldump one. mysqldumpslow merely takes its sweet time about things, so as to not put undue additional load on your servers, but otherwise its syntax and use is the same.

When I applied all this goodness to upgrade this blog, I ended up with just 3 errors from running the wp-admin/upgrade.php script, after I had gone through the process of adding new GRANTs for that dbuser to access my user’s databases. The errors were that 3 DROP TABLE statements had failed. These were easilly handled manually (I don’t want the applications to be able to DROP anything on their own):

mysql> USE otherdb;
mysql> DROP TABLE IF EXISTS wp_categories;
Query OK, 0 rows affected (0.02 sec)

mysql> DROP TABLE IF EXISTS wp_link2cat;
Query OK, 0 rows affected (0.00 sec)

mysql> DROP TABLE IF EXISTS wp_post2cat;
Query OK, 0 rows affected (0.02 sec)

That’s it. It only took me about 15 minutes to do all of this and to extract the files for the new version of wordpress and copy and move over all the little tidbits (mostly for things found in the wp-content/ directory) to get each of the blogs updated to the latest release. Interrestingly, it took me about 2 hours to write, sanitize and proofread/edit this post.

I’ve run into trouble here and there as the Livna folks keep pulling RPMs from their repos for older versions of the kernels. At the very least, they should leave the kmod-* packages in there for the original kernels that shipped with each release. Then, people can install a release and get a good driver. I had to wait for about 3 weeks after I first put F7 on my home workstation (dual AMD Opteron) before I could get the nVidia driver from Livna because they didn’t have one for the older kernel packages and the newer kernels weren’t booting (turned out to be malformed initrd files, which I later fixed).

Yes, I understand that they take up some disk space, but it’s not really that much perhaps 100M per release to keep all kmod-* packages and their dependencies around.

Livna, if you’re listening, please, give us all the driver packages and don’t remove them. You don’t know which kernels are working for people and which aren’t, so you could really be making things pretty difficult for people.

I’m posting the script, which is still very rough, as I didn’t both taking any time when I whipped it up last night to take care of everything that it really should be doing. Still, I’ll work on it here and there, I’m sure. You can download it from http://www.openbrainstem.net/download/sign-lots-o-keys. If you feel like makeing some fixes, either post your patches (please, create them as a unified diff file, if you wouldn’t mind) and put a link in the comments here and/or on your own blog.

Enjoy!

Let’s see how this goes. If you would like to comment, you can’t post it on my site. Use your own blog and use a TrackBack to this article. Let me know what you think.

Personally, I’ve always preferred the idea of TrackBacks over comments. I just wasn’t quite sure how to explain (nor did I ever take the time to really think about) why I felt that way. So, thank you to Dave Winer for helping me quantify it.

Although I have configured this blog to not have the “Allow comments” option selected by default, existing posts which did have that option on should still permit comments. I will fix this by editing the DB directly. Hopefully, existing comments will still be visible once I do so.

But a new problem has surfaced with 2.2.1 in the admin interface; when loading the Dashboard or the Write or other pages which include wp-includes/js/jquery/interface.js, it freezes up my web browsers. I’ve tried it with Firefox, Opera, Konqueror & Safari, some on both Linux and Windows. The browser eventually lets me kill it (but I have to stop it 2 or 3 times) and then the page will finally load. In browsers where I have debuggers for JavaScript, I find this error:

Error: https://www.openbrainstem.net/blog/peregrine/wp-includes/js/jquery/interface.js?ver=1.2: Error: Error

It’s pretty frustrating trying to use my blog when the admin interface has some buggy JavaScript. I’m going to try to debug it, though JavaScript isn’t my favorite language. I’ll keep you posted if I find a fix.

If you have an OpenID account, you can now use it to comment and to register on this blog, without having to register on this blog. I haven’t required logins to commont on this blog since June of 2006, but still required commentors to fill in their name and email and optionally allowed them to include a URL for their own site. Now, these kinds of things can be done via your OpenID.

I didn’t activate the second WordPress plugin yet, as I haven’t registered an OpenID of my own, nor have I set up an OpenID server.

I’m thinking about standing up an OpenID server on OpenBrainstem. I’m not really sure about this yet, so I’m asking you, my readers, to weigh in on the idea. Post your views as comments to this post. Tell me why I should or shouldn’t run my own OpenID server.

Well, it irritated me enough a moment ago to actually take a look at the full headers of just such a message. Here are the headers added by SpamAssassin:

X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on
       dark-templar.lamontpeterson.net
X-Spam-Level: ***********************
X-Spam-Status: Yes, score=23.0 required=4.0 tests=BAYES_80,DRUGS_ERECTILE,
       DRUGS_ERECTILE_OBFU,HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,URIBL_AB_SURBL,
       URIBL_JP_SURBL,URIBL_SBL,URIBL_SC_SURBL,VIA_GAP_GRA autolearn=no version=3.1.8
X-Spam-Report:
       *  2.5 VIA_GAP_GRA BODY: Attempts to disguise the word 'viagra'
       *  2.0 BAYES_80 BODY: Bayesian spam probability is 80 to 95%
       *      [score: 0.8180]
       *  0.0 HTML_MESSAGE BODY: HTML included in message
       *  1.6 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
       *      [Blocked - see <http ://www.spamcop.net/bl.shtml?201.83.176.249>]
       *  1.6 URIBL_SBL Contains an URL listed in the SBL blocklist
       *      [URIs: tersho.com]
       *  3.8 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
       *      [URIs: tersho.com]
       *  4.1 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
       *      [URIs: tersho.com]
       *  4.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
       *      [URIs: tersho.com]
       *  2.4 DRUGS_ERECTILE_OBFU Obfuscated reference to an erectile drug
       *  0.5 DRUGS_ERECTILE Refers to an erectile drug

(Now that’s one spammy piece of SPAM!)

OK, so I took a look at my ~/.mailfilter file on the server:

### SPAM
if ( /^X-Spam-Flag: *(yes|YES) / )
{
   to "$HOME/mail/.SPAM/"
}

Many of my readers may be eagle-eyed enough to spot the problem right away. If you said, “Hey, you’ve got a superfluous space after your closing parenthesis in your regular expression there,” then you got it.

That regex would match either “yes” or “YES” (they are case sensitive). I did this because at some point long ago, I had a rule on a system that used “yes”, but SpamAssassin today produces “YES” and I just didn’t want to have it missing stuff because of something like that.

I decided to further improve this regex so that it might be less likely I’ll have to “fix” it again:

### SPAM
if ( /^X-Spam-Flag: *[yY][eE][sS]/ )
{
   to "$HOME/mail/.SPAM/"
}

Problem solved.

BTW: the term SPAM originally came to be used in the computer world because of the Monty Python Spam sketch.

There were some databases changes that weren’t handled very cleanly by the update script. I had to drop and recreate the DB from my backup (taken just before starting the upgrade process).

One of things that changed was the way that links are managed. The wp_linkcategories table was “replaced” with a new wp_link2cat table. Unfortunately, the upgrade script didn’t complete the conversion process.

Most of the work required to fix up my links was done within the management interface in my web browser. Not hard, but it took a few moments. One of the categories didn’t make it through the upgrade. Several others (but not all of them) from the categories list now show up, too. Upon further examination I discovered that the only categories that appeared were those which were not assigned to any posts, though, it appears in the UI that they intend all categories to be simultaneously usable for posts, pages & links. However, when I tried to assign a category which is in use for several posts to a link, that link no longer rendered.

The change from a separate set of categories for links to a unified categories system was certainly the right direction. It merely appears that testing of that part of the upgrade code wasn’t very thourough.

Writing this post, I discovered what appears to be a new auto-save feature. Every couple of minutes while the focus is in the post body input field, the auto-save kicks in and a text marker next to the save/publish buttons updates to say “Saved at h:mm:ss” (the time on this notebook). Nice!

I had read about TrackMeNot a little more than a week before on Bruce Schneier’s blog, and so I already knew TrackMeNot was a flawed idea. Peter also makes some very good points in his post, but, unfortunately, it falls short of pointing out some of the more serious problems with TrackMeNot.

I’ll just summarize the problems here. For further explanation, read Bruce’s post:

1. It does not hide your searches (they are still identifiable with you).
2. It’s far too easy to spot (and therefore, far too easy for AOL and others to defeat) and it’s schedule is regular & fixed.
3. Some of the generated searches are worse than what you would try to hide.
4. It wastes lots of bandwidth, while returning absolutely no privacy or security benefit.

I like this quote from Bruce’s post:

Yes, data mining is a signal-to-noise problem. But artificial noise like this isn’t going to help much.

I also disable all SSL3/TLS encryption suites that provide less than 128 bits of key and all 3DES (a.k.a. triple-DES, DES EDE mode or TDES) sets. This is not just because 3DES is insecure, but also because 3DES is so slow. It consumes significantly more processing time and doesn’t really provide much better security than standard CBC mode DES. It’s just not worth the overhead. In addition, there are several vulnerabilities in both 3-key & 2-key 3DES that significantly reduce the complexity to brute-force them. 3DES is not considered a safe protocol.

In their paper titled, “Key-Schedule Cryptanalysis of IDEA, G-DES, GOST, SAFER, and Triple-DES“, John Kelsey, Bruce Schneier and David Wagner describe one weakness found in 3-key 3DES that isn’t present in 2-key 3DES (among other interesting things).

From what I’ve read in the past about browser 3DES support, although nearly all browsers say they use 168 bit 3DES keys (3-key 3DES), many actually use(d) 2-key 3DES (112 bit). I’m not sure how true or false this is in modern browsers, I’ll have to do further research to find out.

Well, it’s just not true.

It’s only a thin wrapper around Microsoft’s Internet Explorer version 5.5 (or later). Since IE stores all sorts of stuff in places on your system without telling you, Browzar can’t deal with all of it. Scott Hanselman has actually shown that Browzar misses the mark on this point.

There are other problems with this, too. For example, this program will not affect any servers that you visit, or any caching proxy servers in between (like at work or a university).

Anonymity on the web is not just about the stuff that’s on your computer, though it’s an important part; it’s also about the things those servers you connect to keep track of and tell each other.

Web browsers such as KDE’s Konqueror, Mozilla’s Firefox, Apple’s Safari (built on/from Konqueror, BTW) and others already support local privacy features. These include Konqueror’s excellent cookie management capabilities and Firefox’s support for auto deletion of cached data. All of these browsers sport these privacy enhancing features, though they have differing approaches and levels of control.

First, they put spam up that includes links to their phishing sites on blogs they troll the net for. This part is very easy, thanks to services like Technorati and Blogger.

Next, “young” bloggers (i.e., those who are still fairly new to the “sport” of blogging), see comments. Either they naively authorize the spam comment, don’t moderate at all or decide to follow the links and check it out before authorizing the comment. If the comment gets posted to the blog, then others who read the blog can fall into the trap. If the blogger decides to visit the pages, they could get sucked in to all kinds of things.

But as I looked at a few of the links, they turned out to cause redirects to either www.abusepost.com or www.spamcop.net (I didn’t make those into links on purpose; DISCLAIMER: GO TO THOSE SITES AT YOUR OWN RISK, I’M NOT RESPONSIBLE FOR YOUR CHOICES). Of course, the vast majority of bloggers, both experienced and just getting started might think that those sites are providing a pretty good service. Looking a little more closely at the form and at the HTML itself reveals that these sites look suspicious. They require your name, email address and website address (which will be the blog that they hooked you at in the first place, for most people).

Were you paying close attention? They require you to provide the exact information spammers want in order to “report” a site that they are already “about to shut down”? Doesn’t make much sense to me.

Do you smell phish or am I the only one?

A word to the wise: Just Say No.

Here are some simple rules for Internet safety, though, they apply (with proper contextual edits) to any online communication:

1. Moderate — Whether it’s comments on your blog(s), forums (which I hate, BTW) or mailing lists. Moderation is currently the most consistently effective way to defeat all forms of SPAM.
2. Never give out your information if you don’t have to — Just because a particular website’s “form” says that it requires your information, doesn’t mean they should be given any. We all know not to publish our credit card numbers online, but it’s amazing how many people don’t understand that your name, email address, street address, phone numbers, websites, employer’s name, favorite color, mother’s maiden name, etc. are not needed by most websites. When in doubt, don’t give it out.
3. The only stupid questions are the ones you do not ask — In other words, ask someone you know who has lots of experience with the Internet, email, spam, security, etc., any questions about specific websites or other items in general. Keeping yourself safe is hard enough to do, but keep trying to do it without the right information and you just might make things much worse.
4. Don’t open HTML emails — If someone sends me an HTML email (and I think it’s worth this effort), I send it back to them with a simple, polite note explaining that for security reasons, I do not accept nor read emails that are not in plain text. Too many people are using stupid email programs like Microsoft Outlook and Outlook Express that have hundreds of severe security flaws when it comes to processing HTML email, alone.
5. Don’t Panic — It can be easy to let fear take over at this point and abandon your dreams of blogging and the “Internet lifestyle”. Don’t worry, it’s not that hard to keep yourself safe. Once you know how to recognize the dangers, it’s easy to avoid them.
6. Think — (OK, this one could sound kinda mean, but it’s not; it’s just a sad truth, so don’t take it too personally) The spammers and the Phishers keep doing what they do because it works. There are just too many people on the Internet who do not think for themselves. You have a brain and I’m sure it functions at least well enough to read this far. I’m sure you have a lot more capacity to figure things out than you might be giving yourself credit for. Being able to think is not enough on it’s own, but with a little bit of knowledge, your brain can be used to help keep yourself, and your loved ones, safe on the Internet.
7. If in doubt, bail out — You don’t have to go any further than you already have when visiting any website or continuing a discussion on IM in a chat room or on a mailing list. You can pull the rip-cord at any time.

I’m sure there are other things that we could put in that list. Perhaps some commenters will try to help me out in that regard. But I think these basics should be enough to get you started.

This is one of my favorite Turkish proverbs:

No matter how far you have gone down the wrong road, turn back.

There were several security fixes and over 50 bug fixes, according to the announcement on the WordPress website. However, I’ve also noticed a couple of irritating regressions. For example, when managing pending comments, it’s always been possible to click on the text next to the radio buttons at the bottom of each comment you are moderating. This makes it easy to select the action you wish to take for each comment, as you have a larger target for your mouse pointer. Unfortunately, this broke with 2.0.4 and clicking the text no longer selects the bullet.

There were a couple of other patches I had to reapply to the code. For example, if you look at the calendars at my blog, you’ll see that dates with a post are displayed very nicely. This is thanks to a small change I made to the template-functions-general.php file. You can download the patch file and apply it to your own WordPress installation, if you like. Then, I added the posted-day class to the style.css file for the theme that I am using.

There are also a few other tweaks I have made to that theme, and I’m planning a couple more. One thing is that when you view a dated page, the sidebars don’t get their background colors set. A minor bug, but I’ll fix it sometime.

Anyway, there were some other code patches I had to reapply, but it only took about 10 minutes to do. I’m going to get some of these patches packaged up and submitted for inclusion in future versions of WordPress.

Here are my 9 reasons why .mobi is a bad idea:

1. You can already serve mobile content from any subdomain or folder, like mobi.example.com or example.com/mobi
2. You can already use content negotiation. If the browser says “Accept: text/vnd.wap.wml”, then return mobile content.
3. You can already use the “handheld” media type in your CSS.
4. You can already create light-weight, semantic HTML that can be viewed on multiple devices.
5. Since “mobi” isn’t a word, it’s not likely to be in the predictive text dictionary on most phones. A good domain for phones would employ a real word. (Actually .com works.)
6. Without predictive text, typing “mobi” on a phone means pressing 6, then waiting, then 6-2-4. A good domain for phones would not use two adjacent letters on the same key.
7. Phones with QWERTY keyboards are likely to have full-fledged browsers that can view .com websites anyway.
8. Dot-mobi domains are expensive.
9. Browsers like Opera can rerender existing web sites to make them viewable on movable devices.

If you see value in .mobi that I’m not seeing, let me know, but I think it will be a failure. We should as soon introduce a .BestViewedWithInternetExplorerAt800by600 domain so we can keep track of all those web pages from the 90’s.

Number 8 on Richard’s list is the reason why .mobi is a good idea … from the perspective of the registrars who are the ones who pushed for the new TLD.

But why not just .mobil ? I mean, come one, it would be so much easier for people to pronounce, even in a wide variety of languages.

Anyway, I think the addition of .mobi is just dumb. Basically for all the other reasons you already stated. Especially number 6; how irritating.

I first read about this on Bruce Schneier’s blog.

I haven’t tried it with any handheld browsers, so if you do, please, post a comment about the results.

Anyway, sites like that are yet another reason why I love Konqueror. It took just 10 seconds to tell Konqueror to pretend to be Firefox 1.0 (on Linux, of course) whenever it connects to “hilton.com”. Presto! No trouble at all. In fact, the whole site renders perfectly.

I love WordPress; it’s just so easy to deal with the SPAM. Still, it will be nice when open-source people finally create software that fully neuters all SPAM.

As for those of you who don’t have your photos up there, yet: some of us (like Jayce^ and herlo and I) would have come over and taken your photo for you so you could get it up there, but we didn’t know what you looked like, so we couldn’t find you.

Next time we can’t find you like that, we’ll have to refer back to your photo…wait, um…

So, get your hackergnotchi in to Gabe (at gabe at gundy dot org).

I’ve seen people talking about the Linux version of Google Earth on the SLLUG Members mailing list. I found an entry on the Fedora SELinux mailing list titled, “Step-by-Step Guide To Creating SELinux Policy for Google Earth“. I’ve seen several other people talking about it already.

But, I was surprised to see that no one whose feed is picked up by the Utah Open Source Planet had yet posted on any of their blogs. So, here it is.

I heard about the new Linux version of Google Earth from my good friend, Evan McNabb via Jabber, yesterday. I downloaded the new Linux version and waited until later in the evening to try it out. Video was a bit scan like on my notebook, but I soon cleared it up.

I’d like to see people comment on their experiences with it, so far. I’ll write more about the things I hear later on.

For the time being, I have turned off the convert smileies to graphics option.

It turned out, that I had to also pull up the offending post(s) and resave them to get that setting to take effect in the db, which is strange, since it was dynamic for the site last time I fixed the bug. Oh, well.

As many of you who use WordPress know, it wasn’t until the 2.0 release that WordPress supported having your admin interface portion of the site encrypted. The way that they implemented this feature in WordPress 2.0 was to have two different URLs that you can configure, the blog URL (where visitors see your blog) and the site URL (where your admin interface lives).

The two URL idea was the right way to do it. I benefit from it, as the admin interface is on a different hostname from the blog. Unfortunately, the WordPress developers made a couple of small mistakes in implementing the use of the two URLs and that’s where the bug that has affected UOSP readers comes from.

But, I know how to fix these bugs.

I will be going through the code and cleaning up those bits that drop URLs into the output, making sure that the blog URL gets used instead of the site URL. However, that will not be quite enough. There are a couple of other things that should be fixed while I’m at it.

The code in WordPress 2.0 has two ways (different function calls) that URLs can be dropped into HTML output. The first is a poorly implemented if-else tree that maps to the parameters as set by the admin and stored in the DB (actually, there are several functions of this type). The second function is a wrapper around the first one and others like the first one. This is a very inefficient design, not to mention confusing.

Another problem is that the two functions in question (i.e. those that deal with the blog URL and the site URL) use the same parameters for different meanings, reversing the result from what one expects.

The right way to fix all of that is to use a set of simple indexed arrays to access those parameters (or a single two-dimensional indexed array). This will eliminate the overhead of the multiple, nested function calls and provide one consistent location for accessing any configured parameter.

His first sentance was:

I post this on my blog cause Peregrine doesn’t take comments unless I’m “logged on” and I had it all typed up.

Sorry for the inconvenience, Gabe. You’ll be happy to know that I have now “fixed” this. The “Users must be registered and logged in to comment” option in WordPress was checked.

I was going to add a trackback to Gabe’s article, but I couldn’t find any trackback URLs on his WordPress blog. Oh, well.

openbrainstem-announce:              "|/usr/lib/mailman/mail/mailman post openbrainstem-announce"
openbrainstem-announce-admin:        "|/usr/lib/mailman/mail/mailman admin openbrainstem-announce"
openbrainstem-announce-bounces:      "|/usr/lib/mailman/mail/mailman bounces openbrainstem-announce"
openbrainstem-announce-confirm:      "|/usr/lib/mailman/mail/mailman confirm openbrainstem-announce"
openbrainstem-announce-join:         "|/usr/lib/mailman/mail/mailman join openbrainstem-announce"
openbrainstem-announce-leave:        "|/usr/lib/mailman/mail/mailman leave openbrainstem-announce"
openbrainstem-announce-owner:        "|/usr/lib/mailman/mail/mailman owner openbrainstem-announce"
openbrainstem-announce-request:      "|/usr/lib/mailman/mail/mailman request openbrainstem-announce"
openbrainstem-announce-subscribe:    "|/usr/lib/mailman/mail/mailman subscribe openbrainstem-announce"
openbrainstem-announce-unsubscribe:  "|/usr/lib/mailman/mail/mailman unsubscribe openbrainstem-announce"

What I was missing was to add these kinds of entries to the /etc/postfix/virtual_alias file:

openbrainstem-announce@openbrainstem.net              openbrainstem-announce
openbrainstem-announce-admin@openbrainstem.net        openbrainstem-announce-admin
openbrainstem-announce-bounces@openbrainstem.net      openbrainstem-announce-bounces
openbrainstem-announce-confirm@openbrainstem.net      openbrainstem-announce-confirm
openbrainstem-announce-join@openbrainstem.net         openbrainstem-announce-join
openbrainstem-announce-leave@openbrainstem.net        openbrainstem-announce-leave
openbrainstem-announce-owner@openbrainstem.net        openbrainstem-announce-owner
openbrainstem-announce-request@openbrainstem.net      openbrainstem-announce-request
openbrainstem-announce-subscribe@openbrainstem.net    openbrainstem-announce-subscribe
openbrainstem-announce-unsubscribe@openbrainstem.net  openbrainstem-announce-unsubscribe

After running postmap and /etc/init.d/postfix reload, it works. :)

The really odd thing is that I wasn’t even looking at this stuff, I wasn’t working on my mail server and it just occured to me how to fix the error, out of the blue. So, I sat down and tried it. I only wish inspiration had struck me when I was first setting this up.

Most of those who will read this already know the dangers of trusting the kinds of email messages like the one I just recently received with the subject line “Your account might be compromised!”, which prompted this post. However, many who read this blog are not of the “technically savvy” or “computer expert” types, so I thought these comments might be useful.

Rule Number 1: NEVER take any email message from a company that deals with money (like banks and credit unions) at face value. That simple rule will protect you from most Phishing attacks.

The Phishing scams use all sorts of tricks to make their emails look legit. This latest one even employed the technique of having someone who actually speaks English write the text. In the past, one very big indicator that an email might not be from the company it claims to be, was the bad translation from some other language to English before it was sent out.

Another common tactic is to send HTML email. This allows the Phishers to create links like [ http://en.wikipedia.org/wiki/Phishing ]. The link looks like it points to the correct website for your bank (for example), but actually goes somewhere else. Unfortunately, these can be hard to expose if you use Internet Explorer, Outlook, Outlook Express or some common web based email systems (like Hotmail & Yahoo!).

If you visit such fake links and you use Internet Explorer, there are several techniques the fake website can use to make it look like it is the real website. For example, there are dozens of still not patched bugs in IE that let a web page dictate exactly what you see in the address bar. So, while you are actually at “http://192.0.2.5/www.chase.com/login.jsp”, IE’s Address bar could show, “https://www.chase.com/login.jsp”, thus making it look more legitimate. Of course, you got there by clicking the link they gave you in that HTML email.

Rule Number 2: Don’t trust HTML emails. Too much stuff can be hidden.

HTML email has many other problems as well, like being able to pull in code or images that actually tell the sender that their email has been read while completely hiding this fact from you. That let’s the spammers know that you’ll read their SPAM.

I could go on and on about this, but I won’t. Instead, I’ll just leave you with a few, simple thoughts:

1. There is no Nigerian Oil Money waiting for you to transfer into your account (money laundering schemes)
2. That’s not Viagra they’re putting in those bottles (generic drugs fraud).
3. You do not need to buy OEM software. (pirated copies).
4. eBay & PayPal (or, for that matter, any bank or credit union) never need you to “verify” or “validate” your account (Phishing).

And, last but most certainly not least:

5. The world will not fall down around you if you don’t immediately forward that chain mail (viruses).