2008-08-23 16:50:39

By Tim Brown

Just been watching the DebConf 8 BOF on the Debian OpenSSL debacle and my gut instinct is that the discussions really focussed on the wrong question. The question shouldn't be how can we expose our divergences from upstream but as I've said before, how we can encourage better relationships between Debian participants and those that operate either upstream or on other distributions so that the many eyes maxim holds. Maybe what is needed is a social network for patches, packages and packagers but whatever, I do not believe a Debian centric solution will work.

Moving on, the BOF discussed how to classify packages that might have a direct impact on the security of the system on which they were installed. Whilst I agree that this is difficult to do because any binary that handles user input might be vulnerable to attack, there are 3 classes of binary that should be immediately considered:

  • Kernel images
  • Binaries that are typically executed as root (be that setuid or indirectly by a controlling process such as init, inetd or cron)
  • Binaries that interact with remote systems either by connecting out or handling incoming connections

Each of these three classes could be detected both with lintian and automatically upon upload to NEW without any intervention and in the latter case should Debian specific patches also be detected, the package concerned could be flagged for a manual audit.

As a final aside, maybe Debian needs to approach Coverity and others regarding automated scanning of open source software. Yes, they're closed source tools, and yes, they're not perfect, but we've already acknowledged that sometimes we need closed source solutions in order to put our users first - I suppose the question is, whether this is one of those times?

Mood: Thoughtful

Music: Nothing playing right now

You are unknown, comment