Steve Kemp writes about security issues with C programs [1]. It seems obvious that if you are going to do something that is overly tricky (such as anything related to setuid programs) then you should have a good knowledge of what you are doing. Steve goes a little further and suggests that anyone who doesn’t know C should not package a C program.
In this debate I have more sympathy for Steve’s position. Security is one of the most important things in software that we develop, if you can’t develop secure software then IMHO you shouldn’t distribute any software. Although it should be noted that the two posts in question don’t directly conflict. Steve’s main point (your should know the code well to do something relevant to security) does not directly conflict with Andrew’s main point that a non-C coder can maintain the Debian packaging files and forward bug reports related to C code upstream.
In the more general case it’s often impossible to know all languages used in a project. It’s not uncommon for a single project to have core code written in C, a configuration file format (which is a programming language), a Makefile (GNU Make is a fairly complex interpreter), Autoconf/Automake (even more complex tools for creating complex Makefiles, and then some Perl or Python to manipulate input or output data. The SE Linux project has code in all those languages plus the M4 macro language. It seems obvious that in a large project the number of people who are capable of understanding all languages which are used is going to be a small sub-set of all Debian Developers. It also seems likely that someone who knows some of the languages really well may be capable of doing a better job than someone who has a passable knowledge of all of them.
For the vast majority of my work in Debian I have been a member of the upstream project in question (for Bonnie++, Postal, Portslave, Maildir-bulletin, and logtools I’m the sole upstream developer). Often I start maintaining a package with the intent of doing the minimum needed to keep it maintained in Debian but then end up doing upstream work, for example I briefly had write access to the CVS repository for pppd when I was maintaining it and I had write access to the KDE CVS repository when I was working on KDE packages (which incidentally was before I became an official DD).
When I first started working on the SE Linux project I aimed to merely package the code in question for Debian. I was not planning on spending seven years doing upstream work!
When I’m working on a project I spend my time working on the things that most need attention. That often means that I get diverted from Debian packaging bugs (which are often minor issues) to work on upstream bugs. In many ways my work practices make me a Debian user and upstream developer who also does Debian packaging rather than a dedicated DD. This of course does have a detrimental affect on the quality of my Debian packaging work – but overall I believe that it’s best for the users!
As an upstream developer who is focussed on Debian there are significant advantages in being a DD. I can immediately upload a new package to Unstable without any delay, and there is the potential to take over a related package (either be given the package or NMU) if it’s the best way to get around a roadblock. Another benefit is that in certain limited situations I can speak on behalf of Debian (in terms of packages I “own”). When it comes to upstream development of SE Linux I can make decisions about how things will be done in Debian and work with other upstream developers to ensure that cross-distribution compatibility works reasonably well.
It seems to me that a fairly ideal process for managing Debian development would have the people who are capable of the hard coding doing so and some people who haven’t got specific coding skills working on the packaging. I would be very interested in receiving patches related to the Debian packaging of the packages I “own” (in Debian it’s widely regarded that a man’s package is his castle) so that I can spend more of my time on the C coding. I’m not bothered about NMUs (a Non-Maintainer Upload – is when someone else uploads a new version of one of my packages to fix a bug). If anyone would like to NMU one of my packages they are welcome to do so as long as there is a suitable combination of bug urgency, simplicity of the fix, and lack of response from me. If someone wants to start NMUing my packages to fix bugs reported by the latest version of Lintian in Unstable (Lintian is the Debian tool to automatically check for packaging bugs) then that’s OK.
Of course there are a variety of other situations that DDs sometimes find themselves in. There have been situations of overtly hostile upstream developers. I try and avoid associating with people who have certain difficulties in interacting with others. If someone is going to change their license and try to back-date the change or create a license that makes it difficult to distribute modified versions of the code then I’m inclined to avoid even using the software, let alone being involved in developing it. This means that the software that I use in any serious way has reasonable people doing upstream development who welcome new people to join their work.
Nice! Its interesting to learn that you are a packager and an upstream developer. I’m surprised that more upstream developers don’t try to help out debian maintainers as much as they can.
OTOH, packaging is, for most packages, primarily a systems administration type process…and sysadmins & programmers are two quite different beasts.
outside of debian (where most programmer types DO have a very solid grasp of sysadmin concepts), most programmers just aren’t interested in sysadmin-type things, which is why a system administered by a programmer is usually a complete mess, with crap slopped all over the place, and vital stuff running out of some programmer’s home directory (which, of course, breaks when they quit and their account is disabled), and other abominations.
similarly, many sysadmins have about as much interest in large programming projects as programmers have in systems administration. most sysadmin programming is writing and/or applying patches; hacking code, Makefiles, configure files etc so that they actually bloody compile; quick and dirty hacks; data mangling tools; systems automation stuff…i.e. mostly sysadmin tools, not applications.
there are people who are interested in and even good at both, but they are the exception, not the rule. compared to the general geek population, debian has an extraordinarily large percentage of people like this.
i.e. two complimentary, but different, skill sets. and two different definitions of what kind of things are “interesting enough” to devote considerable time and attention to.
FWIW, i’m a sysadmin, not a programmer. my basic rule of thumb is that if a project takes more than about 2 or 3 screenfuls of code to write, or if it requires an end-user interface, then get a programmer to do it. anything less than that, i’ll do myself. I’m just not interested enough in C to ever get really good at it…i’m a reasonably proficient amateur C coder and not likely to ever become an expert. Over the years, i’ve maintained several packages within debian that were way beyond my ability to code myself, but which were well within my ability to make small patches to, organise into a logical system according to debian policy, and generally package properly.
for security stuff, though, i tend to agree with you – if you’re doing anything security sensitive then you need a solid understanding of security issues….both from a programmers’ perspective AND a sysadmin’s.
one of my packages, postfix-tls, was particularly security sensitive. i managed to do a good job of it because i had a good knowledge of security from a sysadmin’s perspective and enough C knowledge for read-mostly understanding of the code, PLUS good communication with and trust of the upstream author’s skill. (postfix-tls is now obsolete because the stupid US export crypto laws were changed and no longer prohibit crypto in the main postfix package)
BTW, i’ve always thought of debian as being a distribution designed by sysadmins for sysadmins – because sysadmin types want a coherent, consistent system and the only way to get that is with policies and standards. most other distros are put together primarily by programmers rather than sysadmins – and it shows.
Craig: Good point about the sys-admins skills in Debian. I remember in the early days Debian was THE distribution for running ISPs because a significant portion of the active developers ran ISPs.
[…] http://etbe.coker.com.au/2008/04/14/debian-work-upstream/ […]