Dear Mr Gagné as a fan of your column, as well as your other writing, when the paper copy of LJ was delivered yesterday, I set it aside to read this afternoon. However, I was disappointed to find a substantial error regarding digital signatures in your otherwise excellent April 2004 column “Francois, Can You Keep a Secret?” About 3/4 of the way through your column, you write: “Signing a message makes use of your key by attaching an electronic signature (your public key) to your message, but not encrypting it. The person receiving the message then has a means of verifying that the message did indeed come from you....”
The originator's public key has little to do with it other than providing a means to conduct the eventual verification. In the context of a signed e-mail, a digital signature is a hash (either MD5 or SHA1) of the signed object (a collection of bytes made up of the message text and any attachments) that is in turn encrypted using the originator's private key. Thus you have the original message, perhaps with an attachment, which has been hashed, and the resulting hash encrypted and then attached to the signed object. This process provides a mechanism for two services, establishing message integrity and message attribution. Message integrity is provided by the hash, and message attribution is provided by the encryption of the hash value. Signature verification is carried out as roughly outlined below.
The recipient of a signed message, when they
choose to verify it, simply decrypts the attached
signature using the public key of the purported
sender, re-runs the hash on the received message
and matches the results. If they match, two
things are established: the sender had the private
key associated with the public key used for the
decryption, and the message had not been changed
in transit. If they don't match, either the message
was tampered with or the hash was encrypted using a
private key that did not match the public key used.
Most of the various public/private key schemes—GPG,
PGP or X509 S/MIME—have individual mechanisms for
determining whether it is a key mismatch or a change
in the signed object.
—
Paul M. Livingston
Marcel replies: thanks for the sharp eye. On seeing your message, I was frankly shocked that I would have written something like this. I honestly do know better. I always take great care to make sure that what I write is both easy to understand and accurate. This one slipped by me.
All I can say is wow. Thanks so much for the following four articles [LJ, April 2004]: “Writing a Simple USB Driver”, “The Hidden Treasures of iptables”, “Real-World PHP Security” and “SPF Overview”. I'm already using SPF, but I'm still glad it was there.
In case no one's mentioned it, Greg Kroah-Hartman is
awesome. I've always wanted to baby-step my way into
writing device drivers, and his article was just what
I was looking for. I only wish the LED lamp wasn't $80
(I'm a dad and a small-business owner, so $80 is a
bit out of my reach for a mood light).
—
john
Check out linux-usb.org for other USB driver projects in progress, and check out this issue for a double helping of articles from Greg. —Ed.
I would like to see the article “SPF Overview” from
the April 2004 issue Linux Journal posted to your and
pobox.com's Web sites. This was a very good article
and a project that I hope makes it to the RFC state
real soon.
—
Brent S. Smithline
LJ readers went for SPF in a big way. Watch our Web site and spf.pobox.com for more on SPF adoption. —Ed.
I enjoyed reading the article “Introducing Scribus”
in the November 2003 issue of Linux Journal. I was
wondering whether LJ would consider eating your own
dog food and convert to Scribus.
—
Martin van Nijnatten
Our other non-Linux internal system is going to move over to Linux first. Keep reading for details. —Ed.
I have written a new Rogue-like role-playing game.
Its not completely finished yet and never
will be, but it's already fun to play.
Its home page is
sourceforge.net/projects/lostlaby.
I think there are still too few games like this
for Linux.
—
Markus
I didn't see the January 2004 article [“Monitoring Hard Disks with SMART” by Bruce Allen], but after reading Marshall Lake's comments on SMART [Letters, LJ, April 2004], I checked it out. Here are the results:
[root@gandalf tmp]# smartctl -i /dev/hdb smartctl version 5.21 Copyright (C) 2002-3 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: Maxtor 54610H6 Serial Number: F6030KNC Firmware Version: JAC61HU0 Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 0 Local Time is: Thu Mar 18 11:59:57 2004 MST SMART support is: Available - device has SMART capability. SMART support is: Enabled
I don't like that “Not in smartctl database” portion. If
Marshall has a disk that is the same as mine, it MAY
explain what his problems are. I am NOT going to run
the smartctl command with the -t option given that
kind of information.
Because I never had a problem with disks, I am going to
take my chances. I think a survey of other Linux
users' experiences running smartctl is in order here.
—
HHH
Bruce Allen replies: if you run smartctl -V, you'll notice that smartmontools comes with ABSOLUTELY NO WARRANTY. And we mean it. You, as a user, can get open-source software like Fedora for free. But the flip side of this equation is that you, as a user, also have more responsibility: you have to read the documentation to understand what the software does and ultimately to contribute something back to the Open Source community. If you read the smartmontools Web page FAQ, you'll notice it states very clearly that not having a drive in the database is NOT an issue. Though, as an open-source user, it would sure be nice if you spent a few minutes (as described) to help us add it in to the database.
In fact, another user has already done this for your drive. Fedora is distributed with version 5.21 of smartmontools. If you upgrade to the current stable release (smartmontools 5.30), you'll find that your drive IS in the database.
A few minutes of research with Google (or browsing the smartmontools-support mailing list archive) will show that thousands of people have used these tools without problems. In fact, because they are distributed with virtually every major Linux distribution, I expect the number of users is several orders of magnitude larger.
You wrote, “Since I never had a problem with disks, I am going to just take my chances.” Without intending any lack of respect (I am sure you are an intelligent and thoughtful person) this is foolhardy. If you store any data you can't replace, you MUST back it up. Just “taking your chances” means you will, eventually, lose some or all of it.
Can smartctl provoke problems? As I said in my reply to Lake, the answer is yes, if a disk is already failing. An extended self test with smartctl -t long will read-scan the entire disk surface. If a disk already has problems, such a scan will probably reveal them. For a very marginal disk, it could be the “straw that breaks the camel's back” and provoke catastrophic disk failure. Note that this also applies to backups: the very act of backing up a disk (and thus reading all the files on it) can also cause a marginal disk to fail. Does this mean you shouldn't back up? No! It means you should keep multiple backups, and back up frequently, so that if a disk fails during a backup, not everything is lost.
Please keep in mind that smartctl -t long is simply sending a SMART command to the disk. The effects of that command depend upon the disk firmware, written by the engineers who designed the disk, not on smartmontools. I am aware of at least one disk family (an old IBM deskstar series) where some SMART commands did provoke such problems. smartmontools will recognize such disks (from the database) and issue a warning and a pointer to a site where you can get upgraded firmware from IBM. I am not aware of any such issues with Maxtor disks.
I advise you to re-think what you have said. Burying your head in the sand and taking your chances is not an intelligent and responsible approach.
Thank you for your wonderful article on the
SMART tools [LJ, January 2004]. That
one article was worth my entire year's subscription
to LJ. Using the information in your article, I
was able to run tests on all my machines and found
two drives that were failing but had not yet died.
As a consequence, I was able to preserve my data and avoid
a rebuild. In both cases, the drives were
still under warranty, so the manufacturer replaced
them on the strength of the printout from smartctl.
Excellent! This one has earned a place in my toolkit!
—
tim
I have started a grassroots campaign aimed at convincing IBM to open up and free the programming documentation for its STB (Set-Top Box) series chips (www-306.ibm.com/chips/products/digitalvideo/products/settopbox.html). You can find the campaign home page at www.users.bigpond.net.au/mysite/freestb.htm.
I'm not sure what the origin is of the practice of hiding chip documentation behind an NDA. Surely companies like IBM don't think that an NDA would in some way keep them one step ahead of the other chip manufacturers? I think such information hiding is a relic of the days of proprietary computing, and chips haven't felt the wind of open source, so to speak.
This is a sub-$100, TV-connected Linux machine that uses an STBx25xx chip (www.hauppauge.com/html/mediamvp_datasheet.htm). Here are the hardware specs of the Mediamvp machine: www.shspvr.com/forum/viewtopic.php?p=19411.
Projects like this would benefit from public and
free access to the documentation and drivers
(sourceforge.net/projects/mvpmc).
I'm hoping to spread the word and build public
pressure on IBM to address the issue. Any help that
you might be able to give would be appreciated.
—
Andrew Stuart
As one of your subscribers, I can't help noticing that some members of readers' families are introduced to the benefits of Linux, and LJ of course, at a very early age. Quite rightly so of course, and so far we've already seen nice examples of pictures in the Letters section. However, I would like to demonstrate that the reverse is also true. I recently converted my parents, Mr and Mrs A. J. van der Kleij of Delfgauw, The Netherlands (ages 79 and 77), to Linux by upgrading their PC from Windows 95 to Red Hat 7.3. As can be seen in the photograph, they are very happy with Linux and found the conversion quite easy. They routinely use OpenOffice.org for their paper correspondence and Mozilla for e-mail and browsing. The only drawback is that I get less homecooked food now because they don't need my support as often.
Photo of the Month gets you a one-year extension to your subscription. Send photos to info@linuxjournal.com. —Ed.
Please find attached a photo of my granddaughter the family artist. She's been admiring my small penguin collection and wanted to add one of her own. So as you see, I now have a Chlo�Original Tux for my collection, and I'm sure her artwork is much better than any I could have done myself. Plus, she's a future Linux user.
After reading the article “SPF Overview” by Meng
Weng Wong in the April 2004 issue, I tried adding a txt
record for SPF to my DNS entry on register.com.
After finding no way to do this I sent them an e-mail
on the subject. I got the reply:
“We would like to inform you that currently we
do not support to add txt record to the DNS (name
servers). We sincerely apologize for the inconvenience
caused to you.”
—
Stuart Scharf
A returnpath.biz study showed that 18.7% of legit marketing mail sent in the second half of 2003 was blocked by spam filters. If register.com wants to keep business customers who send newsletters or other marketing mail, they'll have to start supporting SPF. —Ed.
Attached is my first attempt at using the Pandora plugin for The GIMP to create a panorama. The image was taken at the Columbia River Gorge outside of Portland, Oregon. It is actually three images stitched together.
