svn co svn://svn.debian.org/debburn/nonameyet/trunkand join us in IRC, server irc.oftc.net, channel #debburn.
:-)
security.debian.org now, which is superior to the one
we had before (you can use the command dig security.debian.org
to inspect the DNS record). My thanks go to our security and system
administration teams for recovering from the recent overload problem
provoked by an xfree86 package security update. Being
somewhat familiar with that package, I can understand how its large size
combined with Debian's ever-growing userbase starved the security host of
bandwidth.
Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of
insight into what a challenge one particular package is — the thing
sucks up at least half of his time, dwarfing all other stable security
update efforts. You've probably guessed that this package is the Linux
kernel. Due in part to its success, and in part due to OS kernels being
inherently attractive exploitation targets, the Linux kernel is getting a
significant amount of scrutiny from a security perspective. Taking Red Hat
Enterprise Linux as an example, we can see two advisories in the past two
weeks: one on 28 September and one on 5 October. The one on 28 September addressed
eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's
one week later — addressed fourteen (14) vulnerabilities, of which
eight (8) were distinct from the previous advisory. (There was some
overlap because the earlier advisory was for Red Hat's Linux 2.4.x
kernel series, and the latter was for the 2.6.x series.) Those
Debian developers who have ever handled a security vulnerability in one of
their own packages can likely imagine the labor burden this is. Then
reflect that Debian ships and supports a lot more Linux kernel trees than
Red Hat does — this only magnifies the problem.
The good news is that a team of developers focused on stable kernel
security updates has been established. One of its members said to me
today that he has seen a "very positive increase in kernel-related security
activity". It is too soon to declare this problem resolved, but I perceive
no lack of talent or dedication on the part of our developers. I am there
to assist them in resolving the organizational and workflow issues so that
our users can see the fruits of their energy directly.
Similarly, I'm interested to see how the
security.debian.org round-robin arrangement holds up after a
reasonable period of real-world loads, particularly since I expect kernel
package updates to sock the machines about as badly as an X Window System
update.
These issues are not over and done with, so an announcement declaring
these problems vanquished would be premature. At the same time, the
developers and users at large need to know whether or not people have their
attention on them. I am wary of leaders or managers who declare issues
resolved too soon, or proclaim optimism that later turns out to be
unfounded, and have sought to avoid this vice. I apologize if I have
tacked too far in the opposite direction.
I perceive progress in this area. Let me know what you think,
what you need to see, and by what metrics you measure
progress and accomplishment on the security front. You can reach me at leader@debian.org (the
address is already blitzed with so much spam there seems little sense in
obfuscating it).
(After getting some feedback on this entry, it's my intention to post it
with any applicable revisions to the debian-devel-announce
mailing list; please take this opportunity to "patch" this "beta", if
you're so inclined.)
tortoise.deadbeast.net, stuffed into a suitcase and crudely
protected with towels and masking tape, has been obliterated with patriotic
fervor by the TSA, swinging their hammers
to pulverize it.
I guess I could be in worse places, like Galveston. Any DDs in New York
wanna give me a wake-up call in the morning and meet for lunch? (I'm at +1
973 589 1000 x217.) If not, I was thinking I might try to go see the
Statue of Liberty in the late morning. I've been in the NYC area twice
before but never went to see it.
Air travel sucks. Maybe this is the real reason, unadmitted to myself
until now, that Contact resonates with
me. I can almost forgive Robert Zemeckis for that brown smear he did with Tom
Hanks three years before. Then I remember that other brown smear he did with
Tom Hanks three years later.
Okay, I won't blame Hurricane Rita or even Continental Airlines. I'll
blame Robert Zemeckis instead. :-P
I'm okay to go... I'm okay to go...
:-)
This year, however, in addition to that, a couple of mini-conferences
are being piggybacked onto the Oldenburg meeting. These include the GNU Classpath and Debian
Java DevJam and the Debian Security
Summit.
The Java programming language is a divisive issue in the Free
Software community, and has a degree of controversy that sets it apart from
the usual language wars. The dominant factor in this controversy stems
from what Richard Stallman refers to as the Java trap; with the
specifications controlled, and the reference implementation kept
unavailable on DFSG-free terms by, an industry consortium
dominated by large corporations, a Free Software hacker might fear that
using Java will consign them to either having to compromise their
principles by using non-free class libraries (for example), or being doomed
to chase the taillights of standards that could conceivably be tailored to
disadvantage competitors. (Java is not alone in this respect; many people
fear that Microsoft's .NET, despite being openly standardized through
ISO/IEC, will in actuality be completely controlled by Microsoft.)
Despite this peril, Java is attractive to GNU/Linux-using organizations.
The Free Standards Group,
developers of the Linux Standard
Base, has received inquiries about a Free Java standard and
implementation from organizations already committed to GNU/Linux. In my
job, I've encountered an interest in Java from several customers and
prospects. Intriguingly, these institutions are, by and large, very much
aware of the Java Trap. They like the language, and are not strong
advocates of Free Software, but they too are worried about vendor lock-in.
They've seen the success of community-driven development as GNU/Linux moves
from strength to strength, claiming territory formerly held by Microsoft
and proprietary versions of Unix. Even if I can't persuade a customer to
adopt a Free Java stack, I can exhort them to only code against Java
standards that have seen a free implementation. That way, their
development bets are hedged against any "madman theory" of the controlling
vendor. Furthermore, this way they only code to standards that are seeing
independent implementations, and they leave their engineers free to switch
between varieties of development kit. Engineers like flexibility because
it enables them to work more efficiently; sales people, marketing
personnel, and strategists like efficient engineers because they make a
firm more nimble.
That's where the GNU Classpath and Debian Java DevJam comes in. Free Software Java enthusiasts want
to see their implementations fully mature, and are working hard to make it
so. The Free Software community has the opportunity to make its Java
implementation not just an available alternative, but a
compelling alternative to the proprietary ones on technical as
well as licensing grounds. The recent release
of GNU Classpath 0.18 shows just how vigorously this opportunity is
being seized. Having mature software is only half the battle, however;
that software has to be coherently put together and easy for the user and
developer to manipulate. For many of these folks, it's not enough just to
have good, Free Java virtual machines (like Kaffe and SableVM), class libraries (GNU Classpath), compilers
and interpreters (gcj and gij, respectively, from
the GNU Compiler Collection), and
application servers (Jakarta
Tomcat, JBoss, and JOnAS, among others). They also
want these technologies to be mutually integrated and easy to install and
use. Good software and good packaging complement each other to drive
adoption of the technology, and that's what the DevJam is all about. I'm
glad to see that representatives of Debian's Java packaging team will be
joining not just upstream authors, but their counterparts at Fedora,
Ubuntu, and Gentoo in furtherance of this goal.
I've approved a budget of EUR 2000, which Petter Reinholdtsen will
administrate, to support the expenses of Debian's participation in the
DevJam. We've received 1500 USD in sponsorship of this event from a
corporate sponsor that chooses to remain anonymous.
The other mini-conference I'll be attending is the Debian Security
Summit. We're bringing together the heads of our Stable Security and
Testing Security teams — the two Joeys, Joey Schulze and Joey Hess,
as well as a bevy of other security-minded people, with the goal of
revitalizing and streamlining our security processes. Several members of
the Stable Security Team have gone dormant over the past several months (or
longer), leaving an increasingly small number people to handle, as of
Sarge's release, not one but two stable releases. This is because
we do not terminate security support for our previous stable release (in
this case, Woody), until some time has passed.
We've had other challenges on the security front. We had what amounted
to a security support hiatus for about three weeks in June, which caused
much consternation. More recently, klecker.debian.org, which
provides the security.debian.org has suffered some occasional
availability problems, and it hasn't always been clear what's caused
them. It's my understanding that we have new hardware in place that can
serve in a backup, supplemental, or failover capacity.
The general feeling at DebConf 5 was that our security apparatus was in
need of attention to make sure it keep pace with the demands being placed
on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and
others over the past several weeks, and I look forward to a productive few
days.
gpg
on my system provoked an unhappy
response.
I had hoped to instead stimulate a discussion* of the problem
— whether a bug in GPG, a bug in the key servers, or both. From
Alexander's explanation, it looks like it's the latter. If a hunk of your
key gets corrupted and then submitted to the public key servers, ever, then
there's apparently no in-band way of signaling that to those key servers.
Apparently you have to contact the humans who administrate the key server
and arrange for something approaching divine intervention (in the sense
that any large database that has many simultaneous reads and writes going
on at all times via defined interfaces really should not have people
mucking around with its innards in an ad hoc fashion). Just off the top of
my head, it seems like one should be able to submit a GPG-signed copy of
one's own entire keyring to the key servers, and have any key signatures
within that be regarded as "authoritative", only capable of supersession by
another signature bundled in a keyring signed by the keyring's owner.
The handling of signatures not in that signed keyring would not
change.
(It does occur to me, though, that this means that the key servers
are susceptible to an annoying attack wherein people can deliberately add
corrupt signatures to other people's keys and promptly upload those
keys to the public key servers. It would also be easy to automate such an
attack. Oy vey. Consequently, it might be worth considering a
key-owner-only update model for keyrings on the key servers.)
Debian relies heavily on its web of trust, and on the GPG application
specifically, and it seems a shame that this problem hasn't been addressed
by now. Do we need a new protocol for communicating with key servers? Is
my suggestion above completely crack-addled? If you didn't get the chance
to flame me for my previous entry, don't miss your opportunity this time
around. ;-)
Another possibility would be to change GPG so it doesn't complain about
the sorts of problems it found in my message, but that seems
suboptimal. Well, okay — I'll say it — grody.
Errors in any large collection of data, such as the keyrings in the
OpenPGP global web of trust, are inevitable. Corrupt data is corrupt data,
should be reported as such, should be susceptible to rectification, and
that rectification should be able to be propagated. It seems the PGP
key servers — the ones I and many other Debian developers use, anyway
— are not entirely succeeding on the last front. What can we Debian
geeks, as prominent contributors to the global web of trust, do to resolve
the problem?
Alexander: I'm sorry I gave offense, if inadvertently and only temporarily.
There are certainly no hard feelings on my part. I don't really know how
to constructively reply to Matthew, given his patient explanation to me at
DebConf 5 that the entire purpose of that specific blog of his is
to serve as a vent for his spleen — he has another for the serious
stuff.
Since it seems to be necessary to state this for the record, I don't
regard damaged packets in a person's GPG keyring to be evidence of flaws in
the owner's character or personality, or as anything to be ashamed of, but
I must admit that I didn't consider that others might do so. I see a
technical challenge to be surmounted (noisy spew from the gpg
program that seemingly can't be eliminated without improving the way GPG
clients and key servers communicate), and that's about it. I welcome
people's ideas on resolving it — is there a Public Key Server
Corrigendum Protocol in our future, perhaps?
*Being relatively new to blogging, it's certainly possible I
have in mind a meaning of "discussion" in mind that is excessively mundane,
and not the norm. I can easily conceive that people who use their blogs
primarily as megaphones to air their grievances (and there are many —
one of my favorites is Billmon) are more likely
to assume others apply their blogs to the same end. I'll need to give that
conception more weight in the future.
;-).
let haskell' = succ haskell98 in
Announcing the Haskell' ("Haskell-Prime") process. A short time ago,
I asked for volunteers to help with the next Haskell standard. A
brave group has spoken up, and we've organized ourselves into a
committee in order to coordinate the community's work. It will be the
committee's task to bring together the very best ideas and work of the
broader community in an "open-source" way, and to fill in any gaps in
order to make Haskell' as coherent and elegant as Haskell 98.
Our task is broadly defined by our mission statement:
The Haskell programming language is more-or-less divided into two
"branches". The Haskell 98 standard is the "stable" branch of the
language, and that has been a big success. A lot of progress has been
made over the last few years in the "research" branch of the Haskell
language. It is constantly advancing, and we feel that it is time for
a new standard which reflects those advancements.
Haskell' will be a conservative refinement of Haskell 98. It will
be the work of this committee to adopt a set of language
extensions and modifications and to standardize a new set of
libraries.
We will strive to only include tried-and-true language features,
and to define them at least as rigorously as Haskell 98 was
defined. This standard will reflect the realities of developing
practical applications in the Haskell language. We will work closely
with the rest of the Haskell community to create this standard.
Your Haskell' Committee is as follows (slightly munged email addresses
follow):
* Manuel M T Chakravarty <chak at cse.unsw.edu.au>
* John Goerzen <jgoerzen at complete.org>
* Bastiaan Heeren <bastiaan at cs.uu.nl>
* Isaac Jones <ijones at galois.com>
* John Launchbury <john at galois.com>
* Andres Loeh <loeh at iai.uni-bonn.de>
* Simon Marlow <simonmar at microsoft.com>
* John Meacham <john at repetae.net>
* Ravi Nanavati <ravi at bluespec.com>
* Henrik Nilsson <nhn at cs.nott.ac.uk>
* Ross Paterson <ross at soi.city.ac.uk>
* Simon Peyton-Jones <simonpj at microsoft.com>
* Don Stewart <dons at cse.unsw.edu.au>
* Audrey Tang <autrijus at gmail.com>
* Simon J. Thompson <S.J.Thompson at kent.ac.uk>
* Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk>
* Stephanie Weirich <sweirich at cis.upenn.edu>
The editors are Isaac Jones and John Launchbury.
Feel free to contact any of us with any concerns or questions. If you
don't know who to direct your questions to, email Isaac Jones
ijones at syntaxpolice.org.
Community involvement is vital to our task, and there will be a way
for members of the community to make formal proposals. In the opening
phases, please use these more informal resources to help us coordinate
Haskell':
* The haskell-prime mailing list. All technical discussion will take
place here, or (if other meetings take place) be reported here. Anyone
can subscribe, and any subscriber can post questions and comments,
and participate in discussions. Anyone can read the list archives.
http://haskell.org/mailman/listinfo/haskell-prime
* A wiki / issue tracking system to document consensus and to track
ongoing tasks. This system is publicly readable, but only
committee writable so that we may present it as the "official"
output of the committee. If you ever feel that the wiki is not
accurate as to the consensus, please alert the committee!
http://hackage.haskell.org/trac/haskell-prime
* A darcs code repository for experiments, proposed libraries,and
complex examples. darcs is a decentralized system, so anyone can use
it, but patches should be sent to Isaac Jones:
http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode
Please join us in making Haskell' a success.
Next.