Hi Guido, Thanks for the feedback.
On Mon, Nov 28, 2016 at 08:13:26AM +0100, Guido Günther wrote: > Hi Roberto, > On Mon, Nov 28, 2016 at 01:02:38AM -0500, Roberto C. Sánchez wrote: > > Greetings all, > > > > I have prepared an update of ImageMagick that takes the work Ben > > Hutchings started and incorporates patches for all remaining security > > issues which have been fixed in jessie [0]. > > > > The nature of my request in this message is: > > > > 1. I would appreciate it if someone would take a look at the package > > (.dsc [1], .changes [2]) and see if anything appears out of place. > > The changes that Ben made combined with the changes that I made > > total about 80 patches, so I would feel more comfortable uploading > > if someone else weighed in. > > If you're asking for code review posting a debdiff to the list might > help people to pick it up. > Quite right: http://people.debian.org/~roberto/imagemagick_6.7.7.10-5+deb7u7_6.7.7.10-5+deb7u8.diff > > 2. Also, I am wondering how to handle testing. After I finished > > integrating all of the patches I found that the test suite failed to > > pass (though this did not cause the package to fail to build). I > > built the last wheezy version of ImageMagick (deb7u7) and found that > > all the tests passed for that version. I carefully audited the > > patches, found some mistakes which I corrected, found some changes > > which had later changes in upstream to partially revert or correct, > > etc. After all of that, I have the unit tests passing again. Is > > there more extensive testing that I need to do? > > Having the unit tests pass again is great! If there are no autopkgtests > it boils down to manual testing afterwards (e.g. by issuing typical > invocations of programs that depend on imagemagick like ikiwiki and > testing packages that link against libmagick*) and a call for testing of > built packages on the list might help too. > I suppose I should have been more clear in my request. The built packages are there (retrievable by the .changes file I linked in my original message). A very small number of the Debian bugs had files that could be used to produce buggy insecure behavior, but I was hoping that there would be something more comprehensive to check for regressions. However, the unit tests themselves appear (at least to me) to provide excellent coverage, so they may be sufficient. In any event, I have exhausted my available time for the month, so if anyone out there (especially heavy users of imagemagick, as I am not personally a particularly heavy user of imagemagick) could test these packages, then that would be excellent. > > 3. I am seeking advice about how to handle the issues which do not have > > a CVE ID. On the security tracker page the issues to which I refer > > appear with an ID starting with TEMP. For the moment I have > > annotated the changelog entries that correspond to specific CVE IDs > > with those IDs and, based on the pattern in Ben's changelog entries, > > I have not specifically annotated the issues. Is this the correct > > approach? When I post the DLA, would I likewise list those issues > > without specific IDs? > > If there are no CVE IDs you use bugs in the Debian BTS to identify the > individual issues. Having the bugs in the BTS makes it easy to track the > status of bugs in other releases too. If there are lots of them it makes > sense to group several bugs in one report. The jessie report lists > several already. > OK. Thanks for this. I will spend a few minutes later on today to gather up the relevant bug numbers and then add them to the changelog entry (rebuild the package, naturally) and then update my draft DLA with them. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature
