Debian Addresses Security Problems 118
An anonymous reader writes "After suffering manpower shortages and other issues, Debian says it has finally addressed concerns that it was falling behind on security. Debian's elected leader Branden Robinson yesterday flagged an inquiry into the processes by which security updates are released, citing a potential lack of transparency and communication failures. It was also an appropriate time to add new members to Debian's security team, as several have been inactive for a while, Robinson said. Debian initial security problems can be found in this earlier Slashdot posting."
1000 developers? (Score:2, Interesting)
The problem with Debian (Score:5, Interesting)
IMHO, that's why they have a shortage of manpower, because it's just not easy enough for people to jump in and help.
We need a Linux Security Information aggregator (Score:4, Interesting)
A less obvious but perhaps more frequent problem is where security problems are discovered and announced in upstream packages, but the information doesn't flow down to all the distributions. There's no formalised or automated mechanism by which distribution security teams get alerted to relevant upstream security fixes. You might get duscussion of the problem on a mailing list which is specific to the upstream package, but the Debian Security team can't be expected to subscribe to all those lists.
Similarly though, you can't rely on upstream maintainers reliably notifying 19 (or however many) distribution security contacts for each security-relevant release. In the specific case of Debian, this sort of thing is the Debian package maitainer's responsibility. However, there are thousands of Debian packages; some of the maintainers are very responsive and some are less so. Even the responsive ones go on vacation sometimes.
I'm an upstream maintainer. I'm pretty sure that for some of the distrubutions, nobody has subscribed to the mailing list where security problems would be announced (bug-whatever@gnu.org). In this particular exmaple, Debian isn't one of them - the Debian maintainer in this specific case is very active.
However, having a single point where Linux-relevant security announcements could go would be useful. BUGTRAQ simply isn't it (partly because its mailing list software is somewhat broken, also because of the noise level due to broken out-of-office response programs, and because solving this problem isn't the goal of that mailing list). That way, at least the Debian Security team - among others - could count on being notified reliably about known problems.
Of course then you still have a workload for the security team of analysing problems, deciding on responses and preparing NMUs. That may indeed require more people - I'm not claiming that an aggregated feed of upstream security concerns and fixes solves the whole problem.
RPM and Deb (Score:4, Interesting)
The baroque complexity of the debian/ subdirectory and build processes compared to an rpm
Similarly, while apt trailblazed decent dependency handling, the latest versions of yum are catching up and, extremely importantly, it is far simpler to set up a yum repository than an apt one - so third party developers can very simply set up a website with a small repository and manage it themselves.
There'd be initial massive outcry I guess, but if Debian were to just adopt rpm, life would become much simpler.
Re:I wouldn't know (Score:4, Interesting)
You can have a very basic installation for about 100 MB. I personally think that's already a bit heavy, but it's definitely better than a lot of other distros. From there, you can get almost everything you care to mention, just by runnig apt-get install package-name. Dependencies are all taken care of automatically. You can customize how many questions you are asked during installation, from no questions to lots of options (and you can always re-run the configuration questions later).
In terms of quality, you can hardly go wrong with Debian. Everything is tested and tested again before it goes into stable (which is why there are such long times between releases), but even the packages in unstable tend to work just fine. I'd say unstable is about as up to date as Slackware-current, so if that's what you like, Debian can give it to you too.
Upgrading from one version of Debian to another is as simple as setting the right apt-repository and running apt-get update && apt-get dist-upgrade.
I don't know what more to say. Just try it for yourself.
(And for those who think I'm a Debian zealot: it's worse than that. I use OpenBSD at home.
Re:RPM and Deb (Score:5, Interesting)
I've always hated the RPM-based distros for getting more successful using an inferior technology and giving many people the impression that package management on Linux was hard, while Debian made everything easy with apt-get.
However, the times have changed. apt-get works for RPMs now, and automated package managers are finally working for RPM-based distros. Maybe the time has come for a standard in packaging land, and maybe that standard can indeed be RPM.
However, notice the many maybes. Having a standard is only helpful if every distro actually uses the same packages, and I'm not very sure that is going to happen. Without that, software still has to be packaged separately for each distribution, and there is little use for standardizing the format. In that case, the best course for Debian is to stick to their own format; if it ain't broken, don't fix it.
Re:RPM and Deb (Score:4, Interesting)
Besides, who wants their apt-get upgrade to stop every 2 minutes and ask inane questions?? Debconf sucks! Even with priority=high it acts like a stupid nieghbor that always wants to chat. RPM gets this right: install sensible defaults and let the user change stuff using a sensible interface AFTER the package is installed.
Finally, it's looking like development on apt/dpkg is largely stalled out. At least, except for package signatures, I haven't seen a user-visible change since, oh, 2000 or so.
Yum, on the other hand... COULD IT BE ANY SLOWER?? "apt-get install nmap" takes all of 4 seconds. "yum install nmap" on FC4 takes over 30 seconds as it draws endless progress bars. I have no idea why it takes so long. I like Yum's simple config files, but it's moot until they fix its speed issue.
Connectiva got it right. It's a shame rpm-over-apt hasn't caught on.
Re:GOOD (Score:5, Interesting)
I could give a rat's ass about the politics of the distro.
Or the cost.
I run Debian because it is the easiest distro I've ever found when it comes time to update/upgrade.
I simply can't afford (nor can my customers) to take a machine to bare metal for an upgrade. And while most distros really try to make the upgrade from one version to the next easy... most are not "production quality" as far as I"m concerned.
If you want to deploy systems with a long service life, Debian is a fine choice.
Re:RPM and Deb (Score:3, Interesting)
Regarding format, though, I still believe DEB's win for flexibility, accessibility, and a simple, straight-forward design. Baroque is hardly the word to describe the "./debian" maintainer scripts directory. What does one find in "./debian"? control, changelog, copyright, README.Debian, rules (the build Makefile), and optionally the prerm, postrm, preinst, postinst scripts. Whatever else a maintainer puts in that directory that is useful for the build process is entirely subjective to the helper tools they might use (like debhelper).
DEB's are simply two tarballs archived together, data.tar.gz, which contains the package files themselves, and control.tar.gz, which contains the maintainer scripts. If you did not have dpkg installed on your system, but wished to extract the files and information from a DEB, you would simply use the tools ar and tar. To do the same with an RPM is to open up a hex editor to find the end of the RPM header, then use dd to cut it off and output the remaining tarball. (RPM format [rpm.org]) How many people know or want to know how to do that?
The other flexiblity that DEB's have that RPM's don't (didn't?) is that maintainer scripts can be written in any language the maintainer wishes, as long as the interpretor is installed at the time the script runs. If you're maintaining a Perl package, it's reasonable to assume that Perl can be installed as a (pre-)dependency and used to run the maintainer scripts.
Debconf, for example, is one of those optional helper tools the maintainer is encouraged to use when questions must be asked of the user/administrator at installation time. Gone are the days when DEB's could not be installed unattended. Using Debconf allows the maintainer to provide those questions, and allows the user to view them using one of multiple interfaces, or to ignore them completely. Additionally, po-debconf makes it trivial to add multilingual support for those questions.
There is plenty of documentation, utilities, and helper tools to create a Debian package, and on-line resources such as IRC, email lists, and forums. An interesting thread to read dates back from 1996, titled "Why the .deb format? [debian.org]". Also, take a gander at this FAQ [debian.org].
Really, comparing RPM's to DEB's is like comparing apples to oranges. RPM maintainers may baulk at the "debian/" directory and maintainer scripts, but I personally baulk at having to learn yet another spec file format for RPM's and being restricted to using librpm or a hex editor to access the data contained within the package.
Re:RPM and Deb (Score:3, Interesting)
I had managed to delete all of the symlinks under
*Fortunately* the RPM database contained all of the information I needed to reconstruct the symlinks which were created by the packages.
I work with debian systems, so it occurred to me to see how I would achieve the same success on debian systems.
So far as I can tell, symlinks are not listed in any debian 'database' on the system where the package is installed, unlike RPM where the info is right at your fingertips.
The closest I could find for debian would be to troll through the install scripts looking for where they create symlinks.
If anyone has a one-liner which will deliver a list of symlinks that should exist on a debian system I'd like to see it. Yes, one-liner. Thats what I used on RPM.
From the RPM man page;
--dump Dump file information as follows:
path size mtime md5sum mode owner group isconfig isdoc rdev symlink
So with rpm -qa --dump
if the last field isn't an X its a symlink. Easily extracted and processed.
Ok NOW someone tell me deb is superior.