Charles Curley's Weblog

What is it with OpenOffice.org (OOo)/LibreOffice (LO) and labels and mail merge? OOo/LO have had mail merge and label creation for years. Both have always been awkward to use. For one thing, I always end up searching the net for a current set of instructions when I want to use either.

Worse, it's always buggy. With different bugs.

Every so often I need to make a set of tickets and ticket stubs. The tickets and stubs require continuous serial numbers printed on each one. The tickets and stubs have to be attached until the seller sells the ticket. The serial numbers must be continuous so that we can account for all tickets, sold and unsold.

I found a set of instructions for creating labels with serial numbers, and they work if you only want to use each serial number only once. However, when I tried using each number twice (ticket and stub), everything worked, except when LO printed to the output file: at each page boundary it skipped a serial number. Arrrggh!

My solution was to abandon the mail merge capabilities of LO entirely. I created a page of tickets and stubs, five up, for use on business card stock. I included everything except the serial number. I adjusted the page style to use 8.5x11 paper, not the weird size OOo came up with. I then exported that to PDF as tickets.raw.pdf.

I then wrote a program in Perl to apply the serial numbers and create an appropriate number of PDF pages. The last step is to use pdftk, the PDF Tool Kit, to stitch the PDFs together into one monster output file.

This is not a solution suitable for the average secretary. Neither is searching the Internet and trying and rejecting five different sets of instructions.

For the purient minded, the program is as follows:

#!/usr/bin/perl -w

# Given the raw tickets in PDF, create a new set of numbered tickets.

use lib "/usr/local/share/perl/5.10.0/";

use strict;
use PDF::API2::Simple;

my $leftCol = 72;
my $centerLine = 306;
my $leftCenter = ($centerLine - $leftCol)/2 + $leftCol;
my $rightCenter = ($centerLine - $leftCol)/2 + $centerLine;

my $startText = 626;

my $number = 1;
my $row = $startText;
for (my $page = 1 ; $page < 201/5 ; $page++) {

  our $pdf = PDF::API2::Simple->open('open_file' => 'tickets.raw.pdf',
                                     'margin_right' => 72, 'margin_left' => 72);

  $pdf->add_font('TimesBold');
  $pdf->add_font('TimesRoman');

  $pdf->file ('pdfs/tickets.numbered.' . (sprintf ("%02d", $page)) . '.pdf');
  print ("Saving as " . $pdf->file . "\n");

  for ($row = $startText ; $row > 0 ; $row -= 72*2) {
    print ("Number is $number. Row is $row.\n");

    $pdf->text(sprintf ("%03d", $number), autoflow => 'off',
               x => $leftCenter,
               y => $row,
               align => 'center',
               fill_color => 'red'
              );

    $pdf->text(sprintf ("%03d", $number++), autoflow => 'off',
               x => $rightCenter,
               y => $row,
               align => 'center',
               fill_color => 'red'
              );

  }
  $pdf->save();
}

The pdftk command line to glue the pages together is:

pdftk pdfs/*.pdf cat output tickets.numbered.pdf

In Germany, a man was fined for not securing his wi-fi. Now Chinese authorities have jailed a man for propagating an email falsely claiming that the sea off Shandong province was contaminated by radiation from the Fukushima One nuclear power plant. Apparently the bogus email went viral in Hangzhou, and there was some panic.

Great, criminalize stupidity. Sounds great, doesn't it? Right. We'd have to start by jailing the legislature that passed the law, and closely follow those with the judges who enforce it. Hmmm… That's actually not a bad idea.

There are plans afoot to put LibreOffice (the successor to OpenOffice.org) version 3.3.1 into the next release of Ubuntu, 11.04, Natty Narwhal, due April 28. However, you can have it now on Ubuntu 10.10. Johannes Eva outlines three options and shows how to do each one. His instructions are simple, clean and easy to follow.

I've taken the first option, installing LibreOffice in parallel with OpenOffice.org. It seems to install cleanly. One thing to watch out for: it will copy your existing OpenOffice.org setup into its own directory, .libreoffice. That's fine as far as it goes, but if you need to keep them in synch, that's your problem.

In case you use one of the social networking sites, you might be interested in their vulnerabilities.

Don't get cocky, kid!

— Han Solo

With all the Windows vulnerabilities running around loose, Linux fans have no great reason to be sitting back resting on their security laurels. It turns out that there was until recently a buffer overflow vulnerability in the Caiaq USB driver. It was detected by MWR Infosecurity and reported March 7. They report building a USB device to take advantage of the vulnerability (PDF).

OK, the vulnerability requires a USB key, so physical access. The bad guy waits until department secretary Matilda waltzes away from her desk. He then wanders over to her desk and sticks his Trojan USB device into her computer. He waits five seconds, then withdraws it and walks away. By then the udev drivers have executed the driver, and initialized the device. The buffer overflow exploit carries a small payload, which then executes with root privileges. The payload then further compromises Matilda's computer. Say by appending the bad guy's public SSH key to root@matilda:~/.ssh/authorized_keys.

Linux definitely gets points for quick turnaround. The guys who found the vulnerability also provided a fix. That is usually only possible when the source is generally available. In fact, it was probably someone going through the driver for some other reason who found the vulnerability.

OK, this is an attack which requires physical access to the target, and which can be foiled by good physical security. Yawn, right? Not so fast. The HB Gary scandal shows that HB Gary Federal had potential clients that were interested in just such an exploit.

Buffer overflows due to insecure library functions are a well known vulnerability. Programmers should avoid them not only for security reasons but for data integrity reasons. Even Microsoft has figured this out, and banned certain vulnerable library functions. Four years ago. They even have a header file to identify banned functions in your code.

Here's my question: Does anyone audit the Linux kernel for these sorts of things? How hard is it to write a cron job based on a shell script with something like:

find -iname *.[ch] | xargs grep \(strcpy\|…\) | mailx …

In Political Activists Need Linux, "Brad" briefly describes the HB Gary Federal scandal. For those of you who have played Rip van Winkle for the last three months or so, HB Gary Federal makes malware to order, and their clients include the US federal government and a number of large US businesses. "Brad's" conclusion is that political activists of any stripe, and their friends, political or not, should not be running Windows.

Ironically, HB Gary Federal fell because they made three mistakes. First, they took on someone who were better at cracking computers than they were at securing them. Second, they used the same account to develop software and to administer their mail server. Third, they ran Windows.

Now comes another attack on political activists. This one is aimed at Microsoft's Internet Explorer web browser. The folks at Google who found the attack echoed Microsoft's advice to install their patch immediately. As the author of the article says, it is even better to stop using IE entirely.

Better yet, don't use Windows at all.

Hmmmm… I've belly-ached about people blindly following their GPS receivers before.

Now, two independent articles come to hand within two days of each other, via different channels. Both are on problems with GPS. Neither one cites the other (no surprise). Neither one cites any of the other's sources. Yet they come to similar conclusions. Both provide yet more reasons to take GPS data with a salt shaker handy.

David Hambling, in GPS chaos: How a $30 box can jam your life, concentrates on GPS jamming and how it can spoil a lot more than just your car's GPS receiver.

Lewis Page's Chicken Little report: Sat-nav dependency spells DISASTER! covers this and other possible GPS problems from the point of view of a former Royal Navy navigator. It concentrates more on marine navigation and enumerates several alternatives to GPS. It is also aimed at The Register's more technical audience.

Both point out that jamming GPS devices is quite easy, as the GPS signal is very faint. A reasonably robust jammer dropped next to a major airport near a major naval base or shipping harbor could cause considerable disruption.

Page, in his Royal Navy mine sweeping days, used the Mk I eyeball, charts and related tools, and radar, as well as a plethora of electronic aids such as DECCA, a version of LORAN. Your correspondent, in his youthful yachting days on the east coast of North America, used charts, sextant, fathometer, and the Mk I eyeball for everything from harbor piloting to ocean passages. No radar. No LORAN.

I agree with Page's assessment: GPS is great for navigation, but it is no substitute for good training, discrimination on the part of the navigator and other officers, and using your eyeballs. Jam GPS in a major shipping port, and most ships would revert to radar and eyeball. Aircraft would have worse problems, but none are insoluble.

Both articles point out that a major use of GPS is providing precise time signals. Here, too, sole dependence on GPS is potentially messy (but probably not catastrophic). Consider a marine gyrocompass that uses GPS to improve its accuracy: what happens when the GPS signal goes south? The gyrocompass shuts down. Wrong!

One solution is to design systems to use alternatives to GPS when appropriate. Gyrocompasses are very accurate devices without GPS. Why not turn on an indicator that says, "I've lost GPS" and continue on without it? Similarly with mobile phones: if the GPS fails, use triangulation with local towers. Etc.

Another, parallel, solution is simply for the people in charge of these things to be aware that they can fail, and to know what to do when they do. That gets back to training, appropriate skills, and situational awareness. And that's the hard part.

In case you haven't seen the Electronic Frontier Foundation (EFF)'s Surveillance Self-Defense site, here's their summary:

The Electronic Frontier Foundation (EFF) has created this Surveillance Self-Defense site to educate the American public about the law and technology of government surveillance in the United States, providing the information and tools necessary to evaluate the threat of surveillance and take appropriate steps to defend against it.

Surveillance Self-Defense (SSD) exists to answer two main questions: What can the government legally do to spy on your computer data and communications? And what can you legally do to protect yourself against such spying?

After an introductory discussion of how you should think about making security decisions — it's all about risk management — we'll be answering those two questions for three types of data:

First, we're going to talk about the threat to the data stored on your computer posed by searches and seizures by law enforcement, as well as subpoenas demanding your records.

Second, we're going to talk about the threat to your data on the wire — that is, your data as it's being transmitted — posed by wiretapping and other real-time surveillance of your telephone and Internet communications by law enforcement.

Third, we're going to describe the information about you that is stored by third parties like your phone company and your Internet service provider, and how law enforcement officials can get it.

There is a lot of reading here, for the technical illiterate to the technically ept. The writing is non-technical where that is feasible. Also, in discussing an individual technology or technique, the authors are careful to tell you what it won't do, or what it won't defend you against.