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 firstname.lastname@example.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:
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.
|This article is part of the LWN Grumpy Editor series.|
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.
There are two fundamental tasks which must be performed by a mail client which supports crypto:
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:
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.
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.
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.
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 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.
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.
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.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.
Page editor: Rebecca Sobol
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds