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 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:
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)
Your editor's review of graphical email
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
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
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
- 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
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
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 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
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
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
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
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 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 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
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.
Moreso than some other subjects reviewed by your editor, this one boils down
well to a summary table. So, here it is:
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,
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
Comments (16 posted)
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
Next page: Security>>