At the Texas Conference on Digital Libraries I learned a good deal about federated authentication, and, in particular, about Shibboleth . I've heard about this software before and seeing a real-world application of it has gotten me interested. Having just acquired an OpenID I'm now interested in putting it to use, so the availability of online ID brokers and the reality of having fewer (login, password) tuples to keep track of is ... well, I want it now!
Having a geek streak I want to build a Shibboleth Service Provider (SP) on my own system. I want to know a bit about the parts and how they fit and work together. So I'm following the excellent documentation on the Shibboleth wiki for building the SP on my Mac. Of course, building the SP requires first building and installing a number of packages that Shibboleth uses. The documentation outlines the specific installation configuration parameters. So far, so good.
The first package listed is log4cpp is a library that supports flexible logging to various files and the documentation specifies the parameters for the "configure" script that builds the makefiles. It also includes the following piece of information:
"For log4cpp 0.3.5rc3 and most likely others, the file ../include/log4cpp/Manipulator.hh contains an extra semi-colon (;) on line 29 that needs to be removed before building log4cpp."
This is good to know, because I forgot about it and the build failed with a compiler messages complaining about the extra semi-colon on line 29. I'm happy to have the information and removing the extra semi-colon permitted the build to proceed. But why is this error still in code that was released on 29 July 2005, almost two years ago? I can understand an open source project not implementing new features or even changing existing ones. But not fixing such a simple coding error? Is anyone maintaining the code?Should I worry about the quality of the rest of the code?
During the build process there was a compiler warning in the Clock.cpp module:
"Clock.spp:21:1: warning: use of C99 long long integer constant"
I don't have a lot of experience coding in C++, but I wonder if these kinds of type length issues are the sort that lead to buffer overrun exploits. From a quick check on the web I think that this error has to do with compilers not supporting 64-bit integer types. And while it might not be a security problem, warnings don't instill confidence in the code.
[Ed Niseley had an article in Dr Dobbs last year arguing that there can't be a software engineering discipline as long as software developers cannot predict the effects of compiler changes on the resulting code. He has a point. And, no I don't have a pointer to that article.]
The last problem I have with the log4cpp build is that one of the automated tests fails. Now I'm really left wondering if I should install it or not. If I'm doing research project then an install might be OK. But if I'm thinking about using this code in production then I should refuse to install code that doesn't pass the accompanying automated tests.
This is one of a series of posts about open source software (OSS). I'm all for it. But I think I'm looking for open source software engineering, and that's a different kettle of fish. Isn't it?
Technorati Tags: open+source, OSS, user+experience, software+bugs, software+engineering, systems+engineering, testing, trustworthiness