I'm reliably informed that we're exhausting existing stocks of original 8.04 CDs before switching over to the new ones (no, I don't know exact numbers, though I suspect it won't take too long), but after that any CDs we send out will be 8.04.1.
Canonical is still a small company, and so we certainly do a lot more integration at Ubuntu than we do from-scratch software development; however, anyone who equates integration work with parasitism has clearly never done any of it themselves. An obsession with creating things on one's own is a rather curious one in the free software community. Most of the work put in by Canonical-employed Ubuntu developers is on improving existing software.
Anyhow, some things just off the top of my head that (variously) Canonical, Ubuntu developers on contract to Canonical, and community Ubuntu developers have been entirely or largely responsible for:
Upstart (event-driven init replacement)
significant work on improving suspend/resume support all over the place (kernel, acpi-support, hotkey-setup, etc.)
package management improvements, e.g. Breaks field, triggers, and various graphical tools (you mentioned aptitude; take a look at the apt changelog and investigate how many people there are involved with Ubuntu)
large amounts of GNOME and KDE packaging work
casper (live CD build infrastructure)
initramfs-tools
substantial improvements to most areas of the Debian installer, e.g. proper progress reporting for package installation, rescue mode, much of udev support, Kickstart compatibility, etc.
much of what became LTSP 5
much of the initial X.org modular tree packaging, and xresprobe
usplash
This is probably biased to things I've been near, and I'm certainly not going to try to enumerate everything as I'd like to do something else with my week, so I've certainly left out a number of interesting projects. Company-wide, our staff are in the Maintainer or Uploaders fields of nearly 5% of the source packages in the Debian archive, which is not too shabby for a small company, and in many cases they do work on those packages on work time. Aside from that, if you want to know what Ubuntu developers do all day, you could always do some genuine research and look through the mail archives of the various *-changes lists!
I don't think the milestone release announcement (which, BTW, was sent to the developer announcement list and was not a "press release") particularly misrepresents anything as being Ubuntu's work when it isn't; right up at the top it talks about "the absolute latest and greatest software the Open Source Community has to offer". Bearing in mind that the intended audience for milestone releases is developers and enthusiastic testers, I don't think this is particularly unreasonable - the people preparing these notes are more interested in describing major things that need to be tested than anything else. However, anyone who feels they are short of acknowledgements should feel entirely free to add them, as the release notes are in wiki-mode while they're being prepared.
That's not true. Passwords are transiently in the cdebconf database, yes, but that's in memory and they're meant to be cleared out before that database gets saved; even if that database does get saved, it's only supposed to be to a file in a ramdisk that's not copied to disk at the end of the installation. This vulnerability arose because both of those defences failed.
As others have said, the patch removes the passwords from the saved cdebconf database in/var/log/installer/cdebconf/ and then chmods the databases 600 for good measure. We will be considering making updated installer images available, but since so many people have the vulnerable images it's necessary also to take adequate measures to protect them, and that comes first.
The code mentioned that was supposed to clear out the password from the database wasn't "a script to fix it after the fact"; it was in the same bit of code that dealt with asking the password, and had it worked as intended the password would never have ended up in cleartext in any file on disk in the first place;
A better solution was also in place (making sure that passwords were stored in a separate database never copied to disk) but this failed to work due to a subtle cdebconf bug;
The first user account is created after the base system is installed;
I had a conversation with Joey Hess about this bug last night, and far from being scathing, he was somewhat relieved that Debian escaped this particular manifestation of the bug essentially by luck, and acknowledged responsibility for one of the original design decisions in base-config that meant we weren't as well-defended against this sort of error as we might have been.
I'm happy to take responsibility for the lack of testing that meant we didn't spot this earlier, but it's not quite the trivial stupid mistake that people are making it out to be.
The release team went over the remaining issues listed as concerning the next release and determined that either we could live without them, or fix them via security.debian.org.
We listened to the community, held a community meeting about the artwork, and went with what the community suggested: namely to use less controversial images for the GDM theme, the gnome-session splash, and the desktop wallpaper. We certainly didn't refuse to listen.
You're out of date by nearly a year. 'apt-get update' only updates your local package lists, it does *not* upgrade packages. You need to upgrade to 3.6.1p2-7.
Updates to unstable only happen once a day. Even if they happened more quickly on the master server, the mirrors only sync once a day anyway.
Unstable was fixed in the first daily update following the announcement.
1:3.6.1p2-6 is *not* fixed; you need 1:3.6.1p2-6.0 or 1:3.6.1p2-7 for unstable. A fix will be released for testing shortly too (since upgrades to testing are currently largely stalled due to glibc 2.3.2).
If you didn't care about the existence of cvs.debian.org for the last whatever number of years, then you won't need to care about Alioth. This is really just replacing all the manual setup and administrative tedium that went with cvs.debian.org. (Actually, I don't understand why it's being reported on/. in the first place, but anyway.)
Yes, security.debian.org, non-us.debian.org, qa.debian.org, and nm.debian.org were hosted on our machine there. Work on restoring all of them to another machine is already in progress. Packages aren't too much of a problem; the infrastructure running there will take a little longer to rebuild.
Fortunately the majority of the critical infrastructure was kept in CVS.
I don't know where you got this from, but you're completely misinformed if you heard that the Apache packages are being moved to non-free. Although there are some oddities with the way Apache is packaged in Debian, the approach we took was to actually talk to the Apache people (shock! horror!), and to determine that this wasn't going to be a problem in practice.
It's the armchair developers who panic. The real developers talk to people and try to get things sorted out.
Once we looked at it more carefully, it actually turned out to be not even as bad as that. The last count I had was down to 91 non-free documents and 93 documents with no licence (which are arguable, but they probably come under the general LDP Licence which is free). I haven't had a lot of time recently so the database isn't up to date with this.
FYI, Debian doesn't have a problem with the LDPL as it currently stands. The old LDPL didn't allow modification, so it was non-free, but the new one is fine by us (for whatever that's worth).
I have a horrible feeling that a lot of the problems over the last few weeks stem from over-reactions and not enough communication on everybody's part... I've been keeping David Merrill up to date, but perhaps not everybody else.
it is baffling to me why the Debian nuts think documentation needs to be under its own special licence instead of using the GPL along with the software it documents
It's baffling to me too why you think we think that.:-) Nobody in Debian objects to documentation being under the same free licence as the software it documents.
why does Debian feel the need to exacerbate this shortcoming even further?
The "GNU Writing Movement" wasn't started by Debian. I think you've got your people mixed up.
Debian did no such thing, and this story has nothing to do with Debian. I'm the Debian LDP maintainer and I found out about this project from Slashdot.
There is no such thing as "the Debian license". I don't know the details of your documents, but statistically they're more likely than not to be within Debian's definition of free (not that I suspect you care one way or the other).
Slashdot Mirror
I'm reliably informed that we're exhausting existing stocks of original 8.04 CDs before switching over to the new ones (no, I don't know exact numbers, though I suspect it won't take too long), but after that any CDs we send out will be 8.04.1.
Canonical is still a small company, and so we certainly do a lot more integration at Ubuntu than we do from-scratch software development; however, anyone who equates integration work with parasitism has clearly never done any of it themselves. An obsession with creating things on one's own is a rather curious one in the free software community. Most of the work put in by Canonical-employed Ubuntu developers is on improving existing software.
Anyhow, some things just off the top of my head that (variously) Canonical, Ubuntu developers on contract to Canonical, and community Ubuntu developers have been entirely or largely responsible for:
This is probably biased to things I've been near, and I'm certainly not going to try to enumerate everything as I'd like to do something else with my week, so I've certainly left out a number of interesting projects. Company-wide, our staff are in the Maintainer or Uploaders fields of nearly 5% of the source packages in the Debian archive, which is not too shabby for a small company, and in many cases they do work on those packages on work time. Aside from that, if you want to know what Ubuntu developers do all day, you could always do some genuine research and look through the mail archives of the various *-changes lists!
I don't think the milestone release announcement (which, BTW, was sent to the developer announcement list and was not a "press release") particularly misrepresents anything as being Ubuntu's work when it isn't; right up at the top it talks about "the absolute latest and greatest software the Open Source Community has to offer". Bearing in mind that the intended audience for milestone releases is developers and enthusiastic testers, I don't think this is particularly unreasonable - the people preparing these notes are more interested in describing major things that need to be tested than anything else. However, anyone who feels they are short of acknowledgements should feel entirely free to add them, as the release notes are in wiki-mode while they're being prepared.
That's not true. Passwords are transiently in the cdebconf database, yes, but that's in memory and they're meant to be cleared out before that database gets saved; even if that database does get saved, it's only supposed to be to a file in a ramdisk that's not copied to disk at the end of the installation. This vulnerability arose because both of those defences failed.
As others have said, the patch removes the passwords from the saved cdebconf database in /var/log/installer/cdebconf/ and then chmods the databases 600 for good measure. We will be considering making updated installer images available, but since so many people have the vulnerable images it's necessary also to take adequate measures to protect them, and that comes first.
For the record:
I'm happy to take responsibility for the lack of testing that meant we didn't spot this earlier, but it's not quite the trivial stupid mistake that people are making it out to be.
The release team went over the remaining issues listed as concerning the next release and determined that either we could live without them, or fix them via security.debian.org.
Although the architecture name is "i386", the packages are compiled with -mcpu=pentium4.
With regard to "Corporate Usage", yes, Hoary's Kickstart support includes support for installations with NIS authentication.
We listened to the community, held a community meeting about the artwork, and went with what the community suggested: namely to use less controversial images for the GDM theme, the gnome-session splash, and the desktop wallpaper. We certainly didn't refuse to listen.
No, they're install CDs only. We will be offering a live CD with the final release, but it didn't quite make the preview.
It's useful, but it's not new; that page has been there for considerably longer than I've been a developer. I think it was created in 1999/2000 or so.
murphy was compromised, but it's not a hoax (at least if you believe this random poster on slashdot ...).
Yes, lists.debian.org runs on one of the compromised machines and is, er, not quite running on all cylinders just at the moment.
You're out of date by nearly a year. 'apt-get update' only updates your local package lists, it does *not* upgrade packages. You need to upgrade to 3.6.1p2-7.
Updates to unstable only happen once a day. Even if they happened more quickly on the master server, the mirrors only sync once a day anyway. Unstable was fixed in the first daily update following the announcement.
1:3.6.1p2-6 is *not* fixed; you need 1:3.6.1p2-6.0 or 1:3.6.1p2-7 for unstable. A fix will be released for testing shortly too (since upgrades to testing are currently largely stalled due to glibc 2.3.2).
If you didn't care about the existence of cvs.debian.org for the last whatever number of years, then you won't need to care about Alioth. This is really just replacing all the manual setup and administrative tedium that went with cvs.debian.org. (Actually, I don't understand why it's being reported on /. in the first place, but anyway.)
Yes, security.debian.org, non-us.debian.org, qa.debian.org, and nm.debian.org were hosted on our machine there. Work on restoring all of them to another machine is already in progress. Packages aren't too much of a problem; the infrastructure running there will take a little longer to rebuild.
Fortunately the majority of the critical infrastructure was kept in CVS.
No problems with Phoenix.
I don't think this choice was up to Debian (I don't really like it either, but hey). BIND upstream decided they wanted to deprecate nslookup.
I don't know where you got this from, but you're completely misinformed if you heard that the Apache packages are being moved to non-free. Although there are some oddities with the way Apache is packaged in Debian, the approach we took was to actually talk to the Apache people (shock! horror!), and to determine that this wasn't going to be a problem in practice.
It's the armchair developers who panic. The real developers talk to people and try to get things sorted out.
Once we looked at it more carefully, it actually turned out to be not even as bad as that. The last count I had was down to 91 non-free documents and 93 documents with no licence (which are arguable, but they probably come under the general LDP Licence which is free). I haven't had a lot of time recently so the database isn't up to date with this.
FYI, Debian doesn't have a problem with the LDPL as it currently stands. The old LDPL didn't allow modification, so it was non-free, but the new one is fine by us (for whatever that's worth).
I have a horrible feeling that a lot of the problems over the last few weeks stem from over-reactions and not enough communication on everybody's part ... I've been keeping David Merrill up to date, but perhaps not everybody else.
It's baffling to me too why you think we think that. :-) Nobody in Debian objects to documentation being under the same free licence as the software it documents.
The "GNU Writing Movement" wasn't started by Debian. I think you've got your people mixed up.
Debian did no such thing, and this story has nothing to do with Debian. I'm the Debian LDP maintainer and I found out about this project from Slashdot.
There is no such thing as "the Debian license". I don't know the details of your documents, but statistically they're more likely than not to be within Debian's definition of free (not that I suspect you care one way or the other).