Comment 9 for bug 2039804

The tests include binary files. Unless something has changed, I can't create a quilt patch that modifies a binary file. The qpdf test suite is full of PDF files, and PDF files are binary files, even when they are hand-created, as many of mine are. This makes including tests in patches challenging. There are a few unit tests that we could include, but they will likely not backport cleanly, which adds additional risk, and I don't think including them in the patch will add any value since the tests are specifically crafted to prove that this bug is fixed, and we have already done that through current releases and the manual tests. The bug affects a very specific pattern in the data. This part of the code that was affected is not actively modified, and the bug involved changing an infrequently-traversed section of code. The tokenizer is very low level and stable, and I did an audit of the code again after this bug was found.

qpdf has been an open source project since 2008 and has been in debian since the beginning. I am the author and debian maintainer. It is excessively unlikely that there will a "next" SRU that will come from other than the version control system, and unless I am hit by the proverbial bus, I will probably be the originator of it. While qpdf has a wide following, if I were not there to fix problems like this and push them through, it is not likely that problems like this would even be entered into an SRU process. It's been quite a long time since there's been any divergence between the debian and Ubuntu versions of the package.

While I agree that more testing is better, I wonder if the benefit we will get is actually worth the effort. The new tests exercise specific case related to this fix. If there is still a bug of this type, adding the new tests will not help us find them. I don't think it would be worth the hassle to tweak the test system or jump through some hoops to allow the binary files involved in the tests to get into the patch -- that is more likely to cause a problem than to prevent one. The same is true of trying to backport the unit tests. qpdf processes millions of pages a day across a wide range of free and commercial systems. My employer processes over a million pages a day all by itself.

In qpdf's 21 year history, 15 of which have been open source, this is only the second data-loss bug, and it has the potential to cause silent corruption of data in rare corner cases. I appreciate the diligence here, but I really think the level of testing that has already gone into this, the inclusion of new patches in the latest release, is adequate, and now that the bug is known, our priority should be getting a well-reviewed, well-tested patch in front of users to minimize the risk of data loss.

Please let me know what else I need to do to get this through. I will cooperate, of course. My intention here is not to argue, but rather to try to assure you that the testing is already quite thorough, most likely exceeding the standard that would be applied to most packages by their authors. We are passing a point of diminishing return. Thanks for considering my argument.