Comment 7 for bug 1090195

jdstrand:

For all patches in the debdiff, the code changes had to be changed and adapted for a somewhat-differing code base. Between 0.07x (which Lucid has) and 0.09x (which is what the patches were written for, and which are all part of upstream code as part of 0.09x which is in lucid-backports), there were substantial code changes. Therefore, I tried to stick to the *original* 0.07x code as much as possible when attempting to backport the patches from the 0.09x code base. Otherwise, the next best step is to request removal of znc from lucid and hardy because of non-fixable security issues in the code (see my notes below for cve-2010-2448.patch if you won't accept leaving the code as-is).

cve-2010-2448.patch:
My reason for NOT changing it from the original code base in 0.07x is because the change to using ++it happened AFTER 0.07x was released, in a later upstream version. My other reason for not changing that from the original 0.07x code is because, the last time I checked, for security patches or other patches for Ubuntu, the goal is to only fix what's really affected, and not change the other code that is surrounding what's affected unless its necessary. Remember: this patch, and all the other patches here, were written for 0.09x. I had to adapt these patches for the 0.07x code.

I'm not going to change that code, unless you tell me otherwise, so the next debdiff will NOT contain the code change you've mentioned. But before you ask me to change the way the for loop handles incrementing itself, I'd ask you to take a look at this first, which is the ORIGINAL 0.07x line as it exists in the package in Lucid, so you can see that changing it to use ++it instead of it++, while not entirely a huge difference, would differ from the actual original code: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/znc/lucid/view/head:/znc.cpp#L1767

======

cve-2010-2934.patch:
Oops, I think my system didn't process the "copy" command when I was copying the link from the upstream tracker, and therefore had the wrong revision number. I'll fix that.

======

cve-2010-2812.patch (although this wasn't identified as being really broken):
mdeslaur helped me out with this one. I believe sometime between 0.07x and 0.09x they changed the PING handling code to differ a bit from 0.07x. mdeslaur came to the same code-change conclusions I did, before I had finished my code base changes to attempt to match upstream, and we kept it at that, since we both came to the same code-base conclusions.