« March 2005 | Main | May 2005 »

April 27, 2005

My first book... sort of

My day job has always been about software and technology, but once in a while I'll delve into something new. A customer's wife had been researching her past and writing a book about it, and I ended up doing the "book design" (also known as "typesetting" ). Many months with Adobe FrameMaker and many reams of paper later, her effort has been published:

Unmarked Grave: Remembering an American Patriot

I don't typically care for historical fiction, but this has been a really outstanding read about the time surrounding the U.S. Revolutionary war and a character who was truly in the middle of it. Meticulously researched, with illustrations and cover art done by outstanding graphic artist Robert Gray. I'd like to think the layout on the inside looks good too: Lord knows we spent enough time thinking about the fonts.

Congratulations, Debra!

Posted by steve at 12:24 PM | Comments (0) | TrackBack

April 25, 2005

Keyword blacklisting for MT Trackback spam

Like many others, I've gotten really tired of trackback spam. Though comment moderation helps on that front, version 3.01D of Movable Type doesn't seem to have anything corresponding for trackbacks. Because these things are indexed by Google, I have long felt an obligation to delete them on a very timely basis. I'm sick of it.

Because I use MT with mod_perl, I understand that the standard add-ons for this don't work, so I decided to hack up my own. I am very weak with the whole MT infrastructure, so elected for something simple that I could understand. This means "It's a hack". But it's been working for me quite well.

I found the code in mt/lib/MT/App/Trackback.pm that seems to process the trackbacks in realtime, and it seemed clear just how an entry could be rejected. So I added my own: the idea is that we know the URL and excerpt from the entry, and if either one contains certain keywords, we'll reject the trackback.

Adding this code to the start of the file: 

use File::Spec;
use MT::TBPing;
use MT::Trackback;
use MT::Util qw( first_n_words ...);
use MT::App;
@MT::App::Trackback::ISA = qw( MT::App );

#START ADDING HERE
my $ban_patternfile = "/tmp/banpat";
my $ban_patternlog  = "/tmp/banlog";

# THIS IS A HACK
sub check_banned {
    my $url     = shift;
    my $excerpt = shift;

    return 0    if not open(XX, $ban_patternfile);

    my @PATS = <XX>;

    close XX;

    my $banned = 0;

    foreach my $pat ( @PATS )
    {
        $pat =~ s/#.*$//;    # dump comments
        $pat =~ s/\s+$//;    # dump trailing whitespace
        next if not $pat;

        if ( $url =~ m/$pat/i  or  $excerpt =~ m/$pat/i )
        {
            $banned = 1;
            last;
        }
    }

    # log if possible
    if ( open (XX, ">>$ban_patternlog") )
    {
        printf XX "%s %s\n", $banned ? "Banned" : "Passed", $url;
        close XX;
    }

    return $banned;
}
#END ADDITION

sub init {
    my $app = shift;
    $app->SUPER::init(@_) or return;
    $app->add_methods(
...

... defines the function that does the banning and logging, and it must then be actually called by adding two lines to the ping sub:

    no_utf8($tb_id, $title, $excerpt, $url, $blog_name);

    return $app->_response(Error=> $app->translate("Need a Source URL (url)."))
        unless $url;

    # SJF HACK
    return $app->_response(Error=> $app->translate("Banned trackback."))  # NEW
        if check_banned($url, $excerpt); # NEW 

    if (my $fixed = MT::Util::is_valid_url($url || "")) {
        $url = $fixed;
    } else {

The file /tmp/banpat - which you can put anywhere - should contain a one-per-line list of words, phrases, or URLs that should be banned, and this list usually comes together relatively quickly. The file /tmp/banlog shows which trackbacks have been blocked or passed, though it shows only the URLs, not the excerpts.

There is nothing about this that is not a hack, and those who actually know the internals of MT can surely do better. I don't know MT internals, and every time I touch MT (including routine upgrades) it's a huge cluster, so the only thing time permitted was an ugly hack. Perhaps it will be useful to others.

... and am I the only one who finds that MT's "preview" doesn't actually do a real "preview"? Ugh.

Update: - it's been some days now, and a quick check of the banlog shows 234 entries, with only four of them being Passed. The offending entries were easy to add to the ban pattern file (and delete in MT). I think that catching 98% of trackback spam has been worth the effort.

Posted by steve at 09:44 AM | Comments (1) | TrackBack

April 11, 2005

Running as non-admin: Office 2003

I have been trying valiantly to run as a non-Administrator, non-PowerUser on my XP box - this is supporting the Limited User Access (LUA) principle that many of us have been espousing for some time. Only by getting experience as LUA can we seriously make this recommendation for others.

About a month ago, Office 2003 started giving me "Preparing to install..." messages every time I started Word/Excel/Outlook, and it burned about 45 seconds every time even though it appeared to run successfully. This, not surprisingly, got very old.

Google was no particular help, and neither were my contacts at Microsoft (somebody suggested it might be related to an MSN Messenger upgrade, but nothing came of that), so this morning I really dug in with the lovely RegMon (Registry Monitor) tool from the smart guys at SysInternals.

The idea, of course, is to look for access denied entries, but it's not so simple to just open up every registry key to which the user does not have rights. Lots of software anticipates these failures by attempting parallel opens on either

  1. the same key but requesting less rights, or
  2. a parallel key in HKEY_CURRENT_USER

Searching for Access Denied through the hundreds of thousands of entries in RegMon showed many pairs of failure-then-success accesses, but one key didn't seem to have this pairing:

HKEY_CLASSES_ROOT\Software\Microsoft\MasterAggregatorForIPP\MSDAIPP

I generally expand permissions with a special group ("LUA Hacks") so it documents that the key was opened for this purpose, and now it seems to work just fine.

I have no idea what caused it to break, or why this fixes it, but I can't be the only one having this problem: hopefully this blog entry will help somebody else.

Posted by steve at 12:30 PM | Comments (1) | TrackBack

April 01, 2005

Advisory: USPS Information Disclosure Vulnerability

I've found what appears to be a pervasive, longstanding security issue in a service offered by the US Postal Service, and the details are found in my advisory.

Unixwiz.net Advisory: USPS Information Disclosure Vulnerability

Posted by steve at 01:33 PM | Comments (3) | TrackBack