Debian Addresses Security Problems

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."

Comments

The problem with Debian

[Rosco P. Coltrane]

is that they make you jump through many loops before allowing you to help them. I have several pieces of software that I wanted to contribute to Debian, so I figured I might as well be the maintainer for them. I gave up eventually, because it's just too damn bothersome, and another Debian maintainer took my .debs over for me.

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

[James Youngman]

One of the problems is that, obviously, exploits can be known by The Bad Guys but not the software maintenance community (i.e. upstream maintainer, Debian package maintainer, Debian security folk). That's obviously bad.

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

[Anonymous Coward]

I think one of the main problems for debian stems from the use of .debs. Sure, they are still superior in a fews ways to rpms, but rpm has by and large caught up since rpm v3 and certainly rpm v4,

The baroque complexity of the debian/ subdirectory and build processes compared to an rpm .spec file is really discouraging for developers wanting to package their stuff up for debian.

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. /usr/src/debian/RPMS ...

Re:RPM and Deb

[RAMMS EIN]

Yeah, and you had to post that as an AC just to prevent the Debian zealots (like me) from finding out your identity. :-(

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

[dozer]

I agree with half of what you say. I've made both RPMs and debs and I find that RPMs are the clear winner. They are faster to install, easier to package, and smaller. The "extra flexibility" that dpkg gives you is not only unnecessary, it's a liability.

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:I wouldn't know

[RAMMS EIN]

I used Slack before I switched to Debian, and never looked back. I don't know your reasons for using Slackware, but for me it was that I like to be in control and not clutter my system with useless stuff. Debian allows you a lot of flexibility, but its package management system (which I honestly believe is the best in the world) makes everything a lot easier.

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:GOOD

[Phillup]

The only reason to run Debian is if you believe in the politics behind the distro.

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.