LWN.net Weekly Edition for July 22, 2004 [LWN.net]

Debian debates amd64 port

July 21, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

The discussion over whether to put AMD64 processor support into the Sarge and Sid releases of the Debian distribution has heated up. The discussion has been brewing for some time, particularly since Chris Cheney's post to the debian-devel-announce list on July 1:

The Debian AMD64 port now has more installed packages than even powerpc making it the second most complete port behind i386. The port is still waiting on Scott Remnant to fix dpkg and for James Troup to allow it into the archive. I sent an email to ftpmaster over 2 weeks ago with no response about the archive issue.

Also, I am starting to get questions from companies and universities running Debian asking when amd64 will be an official port since they are planning to switch to Fedora/SUSE if it is not soon. Do we really want to lose users of a popular platform due to a couple DD's lack of response? If you are concerned about this issue as well perhaps an email to ftpmaster@debian.org could help persuade them this is a larger issue than they realize.

After much discussion on Cheney's post, Josselin Mouette proposed a General Resolution (GR) that would require "amd64," based on the pure 64-bit port, to be included immediately in Sid and the auto-building infrastructure, and that Sarge include the amd64 port. The GR also gives amd64 a pass on Linux Standard Base (LSB) compliance, so that non-compliance with the LSB would not be considered a release-critical bug.

The discussion on the debian-devel has largely conflagrated into a flame-fest of near-epic proportions -- mostly unrelated to the merits of including amd64 in Sid or Sarge.

One can understand why Debian users and developers may be frustrated at the lack of progress in an official AMD64 port. It is not unreasonable to expect a response on such an important issue within a two-week period. Even a terse reply is better than silence.

However, it is probably a bad idea to rush the process excessively as well. As Thomas Bushnell states:

Being a part of sid and testing is a requirement for being a part of stable, and regardless of whether something has been excluded from sid for good reasons or bad reasons, it shouldn't be put in stable by some kind of end-run around sid and testing.

Goswin von Brederlow suggests an alternative draft that might make the GR more acceptable. This draft would "overturn the decision (made through inaction) to block amd64 from sid by the ftp-master team," unless amd64 is added to sid, or the ftp-masters team steps up to explain why amd64 should not be added to sid, or there is a change in the ftp-masters team that would "facilitate better communications."

At this time, the GR to force AMD64 into Sarge and Sid is waiting on a fifth sponsor to move its status to discussion. Cheney had originally signed on as a sponsor for the GR, but has apparently withdrawn his support for the GR. It is probably for the best that this GR does not come to a vote, in order to allow everyone some cooling-off time on the issue.

It is a shame to see something as desirable as an official amd64 port becoming the victim of poor communication (or no communication) and/or personality conflicts. Though there are indeed technical issues to be sorted through to make an official amd64 port happen, it seems that they have taken a back seat.

There is little doubt, at least in this writer's mind, that 64-bit extensions to the x86 architecture are likely to become the standard over time -- and sooner than the next stable release of Debian after Sarge. If the amd64 port is delayed until after the Sarge release, it seems likely that Debian will lose a number of users who are unwilling to wait until that time to make use of their 64-bit hardware or stay on the 32-bit path.

Comments (15 posted)

The Grumpy Editor, graphical mail clients, and GPG

This article is part of the LWN Grumpy Editor series.

Your editor's review of graphical email clients drew a couple of complaints for having neglected to look at how those clients handle message encryption and authentication. There is a confession to be made here: your editor, despite having been an enthusiastic cypherpunks participant many years ago, despite believing that email should be encrypted whenever possible ("why communicate via postcards" and all that), and despite having pulled down copies of PGP back in the days when it really was important to get as many copies in circulation as possible, has made very little use of tools like PGP and (later) GPG. The need has not been pressing, and the hassle factor has been just a little too high.

Encrypted communications remain important, however. Perhaps, thinks your editor, the current crop of graphical email clients will have made life easier for those who want to use cryptographic technologies with mail. Thus this article, which examines the quality of crypto support in graphical email applications. Your editor has not forgotten his promise to look at non-graphical clients as well; that article will come before too long. Honest.

Email crypto overview

To properly set the context for a review of crypto support, it's necessary to cover some background material. Those experienced with using GPG with mail, and who don't feel inclined to heckle, can probably skip the following material.

There are two fundamental tasks which must be performed by a mail client which supports crypto:

Encryption: encoding the contents of a message so that only the designated recipient(s) can read it. Naturally, the client must also support decryption of incoming encrypted messages.
Authentication: confirming that a given message was really sent by the person it claims to be from. On the sending side, the client must be able to "sign" a message with an encrypted hash of its contents; the recipient must be able to decrypt the hash, confirm that it matches the message's contents and that it was encrypted with the sender's private key. If everything checks out, the recipient can have a high degree of confidence that the message was sent by the owner of the private key, and that it was not modified in transit.

These two functions are completely independent of each other. Plain-text messages can be (and often are) signed for authentication, while encrypted messages need not carry a signature.

There are various other functions the client can provide to help with cryptographic communications. At the top of the list, perhaps, is making it easy to send a public key to a correspondent, and to add a key received from elsewhere to the key ring.

There is another issue which must be kept in mind when dealing with cryptography and email: how the mail is to be formatted. There are two mechanisms in common use:

Inline "ascii armor" encoding. In this mode, GPG formats the message with some surrounding header information and the whole assembly is transmitted as a simple, text/plain message. This is how PGP did things back in the day when you had to download your copy from the bleeding-edge FIDO network; some mail clients still do things that way now.
MIME format, as described in RFC 3156. This format creates a multipart message, one of which contains the entire encrypted message (which can be a multipart MIME message in its own right).

In the modern world, one would think that the MIME format would be the way to go. As it turns out, however, different clients support different formats, and they do not all support both. As a result, you need to know which format your recipient expects if you want to exchange cryptographic messages. The more helpful mail clients can track that information for you.

Finally, it is worth mentioning the S/MIME specification, as found in RFC 2633. S/MIME uses X.509 PKIX certificates for key management; it does not use GPG. There is a certain amount of commercial pressure behind S/MIME; certainly the companies in the digital certificate business like the idea. In the free software community, at least, GPG usage appears to exceed S/MIME usage in a big way. This review will not concern itself with S/MIME other than mentioning it in passing.

Thunderbird

Thunderbird 0.7, out of the box, supports only S/MIME. The user who digs through the menus in search of GPG options will come up empty-handed.

When dealing with missing features in Thunderbird, the first response should always be "look for an extension." The relevant extension in this case is Enigmail; it provides what is, arguably, the best crypto support found in any free graphical application.

By default, Enigmail uses inline encoding for outgoing messages (except for those carrying attachments); that behavior can be changed on a per-message or permanent basis, however. Per-recipient preferences are supported; indeed, Enigmail can be configured to automatically sign and/or encrypt messages to specific recipients, and to use specific keys and formats. Keys can be obtained from public keyservers if desired. There is an operation for including a public key in an outgoing message. In general, Enigmail makes sending encrypted mail easy.

On the receiving side, things work just as nicely. Signed messages are automatically validated and marked as such. Decryption works as expected, though (by default), the user often has to explicitly ask it to download a full message from an IMAP server so that decryption can take place. Public keys can be extracted from incoming mail and saved to the keyring. The "import key" functionality is a little brittle, however; if the message containing the key has been signed, Enigmail will not be able to import it.

Enigmail will optionally remember a passphrase for a configurable period of time, and can be told to forget the passphrase. It also has an operation for the generation of keys within the client; this operation may make life easier for users who are completely unfamiliar with GPG, but, perhaps, it goes a little beyond what a mail client should be providing. There is a "view console" operation for advanced users who want to see exactly what GPG is saying.

Overall, Thunderbird with the Enigmail provides outstanding cryptographic support. One wonders why Thunderbird comes with S/MIME support built in, when the (presumably much more heavily used) GPG support must be added separately.

Sylpheed

Sylpheed has GPG support, though some distributions (e.g. Fedora) do not enable that support. The essential functionality is there, but the edges are rougher than with some other clients.

By default, Sylpheed will send in MIME format. It can be configured to use the inline format on a per-account basis, but there is no way to specify the encoding for an individual message, or on a per-user basis. Sylpheed encrypts outgoing mail for the recipient only; most other mail clients also encrypt for the sender, so that people can read their own mail.

On the receiving side, Sylpheed only understands MIME-format messages. If you send an inline-encoded, encrypted message to yourself with Sylpheed, it will be unable to read its own output. Sylpheed verifies signatures automatically, but does not make the result immediately apparent; see the screen shot for an example of what Sylpheed does when the signature does not check out. This client can be configured to pop up a window with result of each signature validation; it does make these results more evident, but requires the user to be forever dismissing popups. If you receive an encrypted message, the only way to know will be the passphrase prompt which pops up - Sylpheed does not mark the message as having been encrypted.

Sylpheed does not remember passphrases by default, but can be configured to do so, with a configurable timeout. It lacks a "forget the passphrase" operation, however. There is no provision for sending keys, or for importing keys from an incoming message.

In summary: Sylpheed has the features needed for cryptographic communications, but they could be a little better developed. The biggest shortcoming, probably, is the inability to receive inline-encoded messages from correspondents.

KMail

KMail has reasonably good GPG support built into it, with (as of version 1.6.2) one glaring omission: it cannot create or understand MIME-encoded, encrypted mail. When it receives such a message, it recognizes the problem and tells the user about it, but that is not entirely satisfying. KMail does have a special plugin mechanism for cryptographic plugins, and a PGP/MIME plugin does exist. The procedure for installing that plugin is seriously daunting, however, and one would guess that relatively few users go to that degree of trouble. Grabbing, configuring, and building half a dozen new libraries and reconfiguring GPG is an entirely different process than installing a Thunderbird extension. So, for the time being, for the majority of users, it must be said that KMail does not support PGP/MIME. KMail does, however, have support for old versions of PGP (as opposed to GPG), should that still be useful for anybody.

The composition interface works well, with the usual "encrypt" and "sign" options available from the toolbar. KMail has a nice option to "encrypt whenever possible," which means anytime it can find keys corresponding to the recipients. It is not quite as nice as per-recipient preferences, but probably does the right thing most of the time. Since KMail does not support PGP/MIME, it sends attachments in the clear - even if the message itself is supposed to be encrypted.

The receiving side works as it should. Signed and encrypted messages are marked in an impressively garish manner (see the screenshot); fortunately, it is possible to change the colors used.

If configured to do so, KMail will remember passphrases, but with no timeout and no "forget" operation. There is no mechanism to send or import keys. Your editor was also able to crash KMail several times while exercising the crypto operations, which is not a generally good thing. In general, KMail's GPG support gives the impression of being a work in progress. Once things stabilize and the new MIME code is integrated, KMail should have crypto support which is second to none.

Evolution

Evolution 1.5.9 comes with GPG support, though one has to dig a bit to set it up. The "settings" dialog makes no mention of it; one has to go into the edit screen for an individual mail account. S/MIME support can also be turned on in this way. Unlike the other mail clients reviewed here, Evolution requires the user to explicitly supply a key ID before it will work with GPG, and there is no nice widget for the selection of that ID.

Evolution only works with MIME-encoded messages; it cannot create or understand the inline format. Composition works as expected; there is no provision for per-recipient preferences or automatic encryption. Received mail is automatically verified and decrypted, and the results displayed prominently. There is also a button for obtaining detailed information, including the output from gpg (shown in the screenshot).

Evolution will, when told to do so, remember a passphrase "until the end of the session." Selecting "forget passwords" on the "Actions" menu will cause it to forget the passphrase. There is no provision for sending or importing public keys. All told, Evolution has all of the features one really needs to use GPG with email, and not a whole lot more.

Balsa

Balsa comes with reasonably complete GPG support. It understands both MIME and inline format; it creates encrypted and signed mail in MIME format by default, but that can be changed on a per-message basis. There is no provision for per-recipient preferences.

Composition works as usual. If you attempt to send an encrypted message with attachments in inline format, Balsa will warn you that the attachments will be sent in the clear. There is an "always encrypt" option which causes the send to fail if no public key exists in the keyring for the recipient; there is no keyserver capability.

Decryption and signature verification are performed automatically. Encrypted messages are not marked as such. Signature information, instead, is appended to the text of the message. If signature verification fails, a popup window alerts the user to the fact.

Balsa does not remember passphrases, so the user must get used to typing it in often.

Overall, Balsa provides the functionality that one really needs. As is generally the case with Balsa, it feels less slick than with some of the other graphical mailers, but the necessary capabilities are there.

Summary

Moreso than some other subjects reviewed by your editor, this one boils down well to a summary table. So, here it is:

Client	Send		Receive		Recip.	Import	Auto	Passphrase
Client	Inline	MIME	Inline	MIME	prefs	key	encrypt	Keep	Forget	S/MIME
Balsa	Y	Y	Y	Y	n	n	Y	n	n	n
Evolution	n	Y	n	Y	n	n	n	Y	Y	Y
KMail	Y	n	Y	n	n	n	Y	Y	n	n
Sylpheed	Y	Y	n	Y	n	n	n	Y	n	n
Thunderbird	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y

Looking at the table, it is evident that all of the graphical mail clients reviewed have implemented support for GPG-encrypted and signed messages. That is a good start. The sad thing is that, due the the existence of two different standards, these clients cannot all interoperate with each other. Given the history of the old format, and the clear superiority of the new format (which is more flexible, less dependent on GPG in particular, and can encrypt attachments), it really seems that a proper client should, at this time, support both.

These issues will eventually be worked out. Even before then, however, relatively transparent and easy encryption and authentication have been put into the hands of millions of users worldwide. That can only be a good thing.

Comments (16 posted)

What's new in PHP 5?

July 21, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

A little more than a year since the first beta was released, the final release of PHP 5 was announced last Tuesday. As is to be expected with a major version release, this release brings with it a slew of new features and improvements.

Most noteworthy in the new release is the Zend Engine 2.0, what one might call the core of PHP. The Zend Engine is responsible for parsing and executing PHP code, implements PHP's data structures, memory and resource management and more. With the 5.0 release, there are quite a few changes in the Zend Engine. No major version release would be complete without performance tweaks, and PHP 5 is no exception. This release includes a new memory manager, designed with muli-threaded environments in mind.

Naturally, PHP 5 includes some language changes. One interesting addition is the introduction of private and protected member variables. This allows PHP developers to decide whether or not they wish to make a variable visible to a class that extends a class the variable is extended in (protected) or set variables to be visible only to the class that they are declared in (private).

PHP 5 also introduces destructors for objects, something that was missing in PHP 4. (Constructors were present in PHP 4, but behaved differently.) This allows developers to define a destructor for an object that can perform a task when the last reference to an object is destroyed.

XML support has been beefed up in PHP 5. The XML extensions in PHP 5 are based on the Libxml2 library from the GNOME project. PHP 5 supports SAX, which was present in PHP 4, and adds support for the W3C DOM standard, XSLT and SOAP. The changes are covered in some detail in this article. There is also the SimpleXML extension.

Developers who use PHP in conjunction with MySQL will be interested in the MySQLi extension. This extension gives developers access to functions in MySQL 4.1.2 and above. This version supports prepared statements, SSL, transaction control and a number of other features present in MySQL 4.1 and above.

If MySQL isn't to your tastes, the SQLite extension is bundled with PHP 5. SQLite is a C library that implements a SQL database engine which does not require a separate SQL server. For lightweight installations or situations (such as shared hosting) where a PHP developer does not have access to MySQL or another SQL server, this may be of great interest. SQLite requires no configuration, implements much of SQL92 and supports databases up to 2 terabytes.

There are also quite a few new functions in PHP 5 that are worth looking into for PHP developers. The ChangeLog lists the new functions added in PHP 5, most of which (if not all) are already documented in the PHP Manual.

For more cautious PHP developers and users, PHP 4.3.8 was also released last Tuesday to address several security problems that have come to light since the release of PHP 4.3.7. If not upgrading to 5.0, users should be sure to upgrade to the 4.3.8 release.

In all, the PHP 5 release looks like a nice step forward for the PHP project. The changes to PHP 5 should inflict minimal, if any, pain on developers who have been developing on PHP 4.

Comments (5 posted)

Page editor: Rebecca Sobol

Security

Security news

Kernel Summit: Security

The Kernel Summit had a session on security which should be interest to readers of this page, even if you don't usually follow the kernel page. James Morris led the session and noted that a great many security features have found their way into 2.6; including the Linux security module mechanism, the crypto API, the dm-crypt target, IPSec, SELinux, NX bit support, the audit framework, and more.