LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
LWN.net Weekly Edition for March 17, 2005Mozilla is dead; long live SeaMonkey Back in April, 2003, the Mozilla Project stirred things up by announcing a set of changes to its development model and roadmap. Rather than continue to develop one huge suite which did everything, the project would shift its efforts to the creation of smaller, standalone applications. In particular, future development would go into the browser then known as Phoenix, and the mail client called, at that time, Minotaur. The full Mozilla suite was expected to fade away.Over time, as the project continued to make new Mozilla releases, it seemed that the suite might stay around for some time after all. The project made several Mozilla 1.8 alpha releases, and one beta, leading some users to believe, reasonably, that there might just be a Mozilla 1.8 final release afterward. So the February 28 staff meeting summary surprised a number of people with this brief item:
*Mozilla 1.8 final*
- To be discussed tomorrow whether we do one The ensuing discussion was long and noisy. The suite still has a large and dedicated user base, even if it has been somewhat overshadowed by Firefox and Thunderbird. Some developers had been working on Mozilla 1.8 and now wonder why. It seems that, over the last couple of years, the big-picture plan had faded from view, and the Mozilla Foundation didn't go out of its way to remind people of where it was going. That ended on March 10, when the Foundation posted its transition plan for the Mozilla suite. According to that plan, the "alpha" and "beta" 1.8 releases were intended simply to test out the Mozilla backend code. There will be no final, stable, supported Mozilla 1.8 release. The Foundation does seem to recognize that not everybody will have expected this decision:
There is no doubt that the series of 1.8 alpha and beta releases
have caused some confusion about whether there would be a 1.8
product released by the Mozilla Foundation. In addition, a set of
people have done a non-trivial amount of work on 1.8 features,
thinking this would be part of an official Mozilla Foundation
release. This has been a major error on our part.
The confusion was also clearly to be found within the project itself, as can be seen by the fact that the question of whether a 1.8 release would happen or not was left as an open item for discussion at the February 28 staff meeting. In any case, the decision has now been made. And that decision is consistent with the project's stated long-term goals, even if people did have reason to believe that things would happen differently. The interesting question now is: what happens next? What's next, it seems, is that the Mozilla suite gets a new name (almost certainly "SeaMonkey," its longstanding name within the Mozilla Project) and is developed and maintained by a group of volunteers. That group is already organizing itself, and has posted a plan of sorts on the SeaMonkey home page. The first priority will be to get a real 1.8 release out, but the developers are already looking beyond that milestone. A commonly-mentioned longer-term goal is moving over to XULRunner; porting back some of the better Firefox and Thunderbird features is also on the list. The Mozilla Foundation claims to support this course of action. So SeaMonkey will be able to use the Mozilla support infrastructure - CVS, BugZilla, etc. It also appears that it will be able to use the SeaMonkey name, though it appears that there may be a significant debate within the new project about naming before this is all over. The Mozilla Foundation's primary concern, it seems, is that the SeaMonkey releases cannot appear to be an official Mozilla product. The Mozilla Foundation's motives in making this decision are easy to understand. The Foundation's resources are limited, so it wants to concentrate those resources on the standalone applications which are at the core of its stated plans - and which, it must be said, have been rather more successful (in terms of user adoption) than the full-blown Mozilla suite ever was. That suite is free software, however, so it can survive abandonment by its creator as long as there are developers with the time and interest to maintain it. The fact that the Foundation is providing the support infrastructure (and, of course, Gecko engine and the rest of the support code used by the Mozilla suite) is an added bonus. There is every reason to expect that both projects will thrive; in a year or two, this decision may be seen as a good thing by all parties involved.
A modest proposal from Debian's Release Team The big news from the Debian Project this week is a proposal from the Release Team and FTP masters that may result in several architectures being "dropped." The Debian release team and FTP masters are proposing some criteria to determine which architectures will receive stable releases after sarge:
The release team and the ftpmasters are mutually agreed that it is not
sustainable to continue making coordinated releases for as many
architectures as sarge currently contains, let alone for as many new
proposed architectures as are waiting in the wings.
The proposal would not affect the Sarge release, but would take effect for the next stable Debian release, dubbed "Etch." The architectures that are slated for release with Sarge will still go out the door, and will have security support throughout Sarge's release cycle, but would not be included in testing for the Etch release. The proposal would relegate a number of architectures to "second class citizen" (SCC) status, though even that does not come for free. At a minimum, the architecture must have a functioning Debian build system ("buildd") which can run 24 hours per day without crashing. It would also require five Debian developers that use or work on the port to send a signed request for its addition, binaries for the port would need to be built and signed by Debian developers, include "basic Unix functionality," and binaries would need to be built from unmodified Debian source. Finally, the architecture must be freely usable, and the port would require a sufficient user base, or 10% of downloads "over a sampled set of mirrors." To be part of the Etch release, an architecture would have to meet yet another set of criteria. The target systems must be available for purchase, they must be able to compile at least 98% of the distribution's packages, there must be a working installer, and there must be a machine under debian.org, available to developers, for testing. It would also be necessary for the security team, the system administration team, and the release team to sign off on accepting the architecture. We followed up on the proposal with Steve Langasek, one of the Debian Release Team members. Using this set of criteria, Langasek predicts that this would reduce the candidate architectures from 11 (for Sarge) to 4 for Etch -- x86, PowerPC, IA-64 and AMD64. The list of ports is not set in stone. Langasek told LWN that he hopes other ports will "strive for inclusion in the Etch release, and that their efforts will contribute to maintaining the high quality we have today even if they don't end up being released." We also asked Langasek how the Release Team had picked the criteria to be used for future releases.
One of the items in the agenda I had set for this meeting in Vancouver
(with input from the rest of the team) was to talk about setting
per-architecture criteria for etch to address some of the problems we've
seen during the sarge cycle, where we've been fighting fires involving one
architecture or another not being able to keep up -- and what we've noticed
is that it's not consistently any particular architecture, it's been spread
out across the board, so we really needed to tell people up front what we
needed from ports in order to get etch out on-schedule.
As it turns out, the ftpmasters ran with this idea in a late-night brainstorm session even before the meeting officially began, and had some preliminary criteria put together by Saturday morning. By Saturday evening, we'd hammered this into something we all agreed was a good idea, and spent the next couple of days tweaking, refining it as one thought or another popped into someone's head. The release team has invited comments on the plan, and it is undergoing quite a bit of discussion over on debian-devel. We asked Langasek if the proposal would be dropped if there was a strong reaction against it. Langasek said that the Release Team was open to ideas, and was "happy to tweak the specific criteria in use if there are reasons to do so." However, Langasek said that setting basic requirements "shouldn't be all that controversial, because the only alternative to holding our ports to a standard that reflects the demands of the release process really is a slow, unpredictable release." He also said there might be tweaks for ports not deemed release candidates.
It is pretty clear based on feedback that something more than the proposed
unstable snapshot mechanism is desired for those ports that aren't going to
be "release candidates". We don't know yet what form that will take, but
there's been a lot of good discussion about what the needs are that should
be met.
One criteria for release candidates that caught our eye was the requirement that the architecture must be "publicly available to buy new." We wondered if that would mean dropping support for 386 and 486 chips, something that other distributions have done for some time. According to Langasek, processors with the 486 instruction set are still in use.
The truth is that it's still possible to buy chips implementing a 486
instruction set, and a lot of people are still doing interesting things
with them in the embedded sphere -- and it doesn't really cost us anything,
release-wise, to maintain backwards-compatibility with those chips.
There have been a few ABI changes recently that have made current software dependent on an instruction set that's only available in 486 chips and higher; it's possible to emulate around this, but the only implementation currently available has security problems, so it may yet turn out that sarge is the first release of Debian's "i386" port that doesn't actually support true 80386 processors. We've also dropped support in sarge for the oldest of the 32-bit Sparc processors, for similar reasons. From where we're sitting, this looks like a reasonable proposal. It doesn't arbitrarily drop specific architectures, but allows for ports to be dropped from Etch's release candidates if they fail to keep up. This may not be the "magic bullet" needed to ensure more timely releases from the Debian Project, but it should contribute to faster releases overall.
Remembering the crypto wars One of the quieter announcements to come out of last month's RSA conference was this release stating that Dorothy Denning had received the 2004 "Harold F. Tipton Award" in recognition of her career in information security. From the release:
"Over the past three decades, Dorothy Denning has been instrumental
in the battle to secure cyber infrastructure," said Tipton, who
will present the award to Dr. Denning. "She has an extensive
history of developing ways to protect highly sensitive information
for corporations and government agencies."
Ms Denning was certainly an early pioneer in this field. Her 1982 Cryptography and Data Security was, for some years, the book on encryption, access control, and security models. A copy of it remains on your editor's shelf. Dorothy Denning helped pave the way to where we are now. The release omits an important point in Ms Denning's career, however, which would be worthwhile for the free software community to remember. Those who were paying attention at the time will remember the encryption battles of the 1990's, when governments (and the U.S. government in particular) tried to control the spread of cryptographic technology. The breaking point in that debate was the "Clipper" initiative, first proposed under Bush I, then supported by the Clinton administration. Clipper would have required that all encryption used in the United States implement a key escrow mechanism which would enable the government to decrypt any communication which caught its interest. Of course, the government promised not to abuse this capability, honest, trust us. Strangely enough, people didn't trust them. Dorothy Denning was nearly unique in the cryptography community in that she was a strong clipper supporter. Her essay, The Future of Cryptography, remains available; it is worth reading for a scary view on how the net should work. Here's what she was worried about:
Crypto anarchy can be viewed as the proliferation of cryptography
that provides the benefits of confidentiality protection but does
nothing about its harms. It is government-proof encryption which
denies access to the government even under a court order or other
legal order. It has no safeguards to protect users and their
organizations from accidents and abuse. It is like an automobile
with no brakes, no seat belts, no pollution controls, no license
plate, and no way of getting in after you've locked your keys in
the car.
Crypto anarchy, it was claimed, would lead to social disorder and the end of life as we know it. But it could be prevented; all that was needed was key escrow, and the "Skipjack" encryption algorithm, which happened to be classified so nobody could see it. It was thought that key escrow might win on its own merits, but this outcome was not to be left to the whim of markets:
The manufacture, distribution, import, and export of unlicensed
encryption products would be illegal, but no particular method of
encryption would be mandated. Individuals would be allowed to
develop their own encryption systems for personal or educational
use without obtaining licenses, though they could not distribute
them to others.
It should be clear that this view of the world would not sit well with the free software community. We want to be able to develop - and distribute - software which satisfies our own sense of how much security we need. We have little patience for coding in back doors for government, or for anybody else. We do not believe in the security of government-mandated back doors or classified encryption algorithms. Clearly, the proponents of key escrow were not successful. There are two reasons for this failure; the first, and perhaps strongest, of those is economic. Somehow, the Powers That Be subscribed to the absurd notion that there would be a worldwide market for encryption products with an explicit back door for the U.S. government. People in the industry, however, eventually figured out that key escrow and crypto export regulations would destroy their business. They pushed for change, and got it. The other reason, however, is public opposition. The debate was loud, public, and effective. And a significant part of that debate came about as a result of the public release of PGP, which let the strong cryptography cat out of the bag in an irreversible way. Phillip Zimmermann's courageous act demonstrated the repressive power that was poised to swoop down on those who sought to protect their own data; it also made any attempt to control the spread of encryption technology moot. Without the release of that code, the software environment as we see it today might have been quite different. As we fight software patents, broadcast flags, or attempts to restrict peer-to-peer software, we should keep these lessons in mind. These battles can be won, even when strong interests are quite determined in their opposition. And releasing code onto the net can change the world. By developing and distributing our systems, which are designed with our interests in mind, we are helping to bring about a more free future.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||