The Unfortunate Case of Debian's SSL Bug

I feel the need to post about this issue in the hope that similar problems can be avoided in the future.

My initial disclaimer is that I'm not a package maintainer for any of the major distros, so I'm not intimately familiar with the stresses or workloads that they may face everyday. I am, though, the lead developer on a project that I hope one day will be included in major distros.

Whenever I get some interest from potential distro maintainers, I try to stress my keen interest in getting any downstream patches. This is to hopefully lighten their workload as well as to improve the software for everyone.

Unfortunately, it appears to me that the patch that caused the trouble in Debian recently was not fed back to the upstream developers, and if it had, it may have been caught much earlier.

What can be done from an upstream developer's point of view to encourage these upstream patches to keep flowing?

And is it not almost a duty for all downstream package maintainers to send patches upstream whenever possible?

Perhaps in some cases, the upstream packages themselves are not actively maintained, in which case being a distro package maintainer is even harder. But OpenSSL is not such a case.

I've run into 3 cases so far where a bad patch to the libtar library has sneaked into various distros and caused trouble for people trying to compile Barry on their systems. Would it not be better for these distro-specific patches to be fed upstream, and get rejected with a proper reason? Would it not be better for all distro maintainers of a particular package to be subscribed to its development mailing list, and see these issues first hand?

Obviously I think so, but I'd like to hear your thoughts on it. I think it is an issue that needs to be discussed, and now's the perfect time.

Is That A Herd Of Penguins I Hear?

The planning stage for the 2008 Ontario Linux Fest is well under way. Richard Weait recently posted an announcement on the KWLUG mailing list, which you can read in detail in the archives. I'll summarize briefly here:

When:

Saturday 25 October 2008

Where:

Days Hotel and Conference Centre - Toronto Airport East
1677 Wilson Avenue
Toronto, ON M3L 1A5

The venue is at "The Days". There is a shuttle from the airport, and it is an easy connection to the Wilson subway. If there is enough interest, a shuttle from the subway to the Fest can be arranged, so let us know. Since the venue is both a hotel and conference centre, there are special deals on rooms, and ample parking on-site.

Who:

The call for papers is now open. See the Papers page to submit your topic. There are spots open for formal presentations, for lightning talks, for Birds of a Feather sessions, for Demo room sessions, and for Vendor room sessions.

How:

There are also various levels of sponsorships open as well, for FLOSS-friendly companies and groups. See the Call for Sponsors page if you or someone you know is interested, from multi-nationals to family businesses to Linux oriented groups.

How To:

If you have a suggestion, idea, desire, or criticism, we want to know!

Mark your calendars. I hope to see you there!

salimma,

I ran into that performance problem too, with my simple newmail.cc mbox summary program (see update_mbox_cache()). You can work around it by replacing std::getline() with the normal .getline() member of the io class, and using a non-std::string buffer.

It's still processing things line-by-line, which when compared to something like grep, is inefficient. Grep reads large blocks of the file, I think 16k or more at a time, and does its own very fast processing. But replacing std::string with a char buffer made the performance acceptable for me.

I believe the main cause of performance issues with std::string stem from the way iostreams insert a character at a time, and when using std::string, it is not very smart when growing its buffer.

I also find Boost regex to be rather slow at times, but perhaps I'm not using them correctly.

Ontario Linux Fest Rapidly Approaching

As you may know, the Ontario Linux Fest is being held in Toronto on this coming Saturday, October 13. Advance registrations are closing tomorrow (the 10th) at noon, so if you plan on being at the event, register now and pay through PayPal. It's all handled through the onlinux.ca site linked above.

It's going to be a day packed full of Linux goodness. I look forward to seeing you there... I'll be the big guy helping out at the sign-in area.

kelly, I pretty much agree with you about PHP. It is useful in some ways, but once I start programming something of any real size, I start to miss simple things like how the compiler is forced to check the syntax of all code, whereas an interpreted language can let you write some invalid code in if statement, and you may miss it until it runs.

As for operator overloading in C++, that's a bit like saying you won't use C because it has some bloated feature like printf() instead of write(). :-) You don't have to use operator overloading, but it sure is handy when it makes sense to use, such as when creating fundamental types like money values or complex numbers.