(This message is directed to Antoine as he gave me the initial feedback, but I welcome comments and suggestions from anyone). Hi Antoine, Thanks for the feedback on this a few weeks ago. I've been quite busy but I don't want to leave this unresolved, so I am making an effort now to complete this task. On Thu, May 19, 2016 at 01:24:01PM -0400, Antoine Beaupré wrote: > > Nitpicking: "Origin:" could be "upstream", or maybe "vendor" for those > patches. For CVE-2016-0494, specifically, there's this upstream bug > report which I contributed to: > I have updated the origin to upstream and left the java.net URLs referencing the specific commits from which the patches are drawn. > http://bugs.icu-project.org/trac/ticket/12020 > > Well, it's the same bug than CVE-2015-4844, basically, since > CVE-2016-0494 was introduced as part of the CVE-2015-4844. > > I think it's useful for upstream if you share those backported patches > as well, unless they are trivial. It might be useful to send a ping to > our Ubuntu friends since they have the same version on their side. > As far as upstream feedback, I presume I should post my updated patches to either ticket 12020 or 12276. Would that be the best approach? As far as Ubuntu, would I just mail security@ubuntu.com? That seems to be the only email listed on their wiki page (they don't list a discussion mailing list): https://wiki.ubuntu.com/SecurityTeam/ForDebianDevelopers > More importantly, as Markus mentionned earlier, there is an extra change > to modify the compile flags to properly fix this issue: > > http://bugs.icu-project.org/trac/ticket/12020#comment:6 > > Here's an additional change I did on the rules file: > > diff -Nru icu-4.4.1/debian/rules icu-4.4.1/debian/rules > --- icu-4.4.1/debian/rules 2016-01-10 07:34:05.000000000 -0500 > +++ icu-4.4.1/debian/rules 2016-01-30 14:42:45.000000000 -0500 > @@ -7,7 +7,7 @@ > # variables' names with l_. > > l_SONAME := 44 > -l_CFLAGS := -g -Wall > +l_CFLAGS := -g -Wall -fno-strict-overflow > ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) > l_CFLAGS += -O0 > else > > The rules file change significantly between the two debian releases: you > may want to add it to DEB_CONFIGURE_USER_FLAGS instead. > > It is important to understand exactly what's going on in those bugs: > just porting the patches is one thing, but you need to be careful when > you discard chunks. In particular, the above chunk in the squeeze > package was important because of the upstream comment here: > > http://bugs.icu-project.org/trac/ticket/12020#comment:4 > > I have to admit it's not something that I would have thought of myself, > but since upstream noticed that, I think it's important for us to follow > suite! > Quite right. I have to admit that I missed that bit; I didn't read over ticket 12020 as carefully as I should have. I also didn't notice the change for Squeeze since I didn't consult that package prior to starting my work. I went ahead and included -fno-strict-overflow in both the rules file and in the runConfigure script, the latter for the benefit of anyone working directly with the upstream part of the source package. > I think that covers it from my end. The icu package is a difficult > target! Oracle doesn't help us when they disclose vulnerabilities in > Java, which ICU is a part of, yet the upstream is distinct and has to > play catchup to a large secretive corporation. > This has definitely proven a challenge. > I am not even sure the changes are complete even with the > above. Upstream ICU refers to the following bug: > > http://bugs.icu-project.org/trac/ticket/12276 > > ... where they link to another secret ticket. Maybe it would be useful > to share your work there and ask for feedback. Last time they took a few > days to give feedback, so they seem pretty responsive. > I am not totally clear on what sort of feedback I should seek from upstream. Should I just ask for a review of the patches I have prepared? Would I do that by posting to the ticket? Also, Markus suggested testing, but I have to admit I haven't the slightest clue how I would go about testing this. ICU appears to have a test suite, but none of the changes or discussions I have looked at in relation to these CVEs have included any updates to the unit test suite to account for these changes. I was also unable to find any evidence in the unit tests that the features affected by these CVEs are covered anywhere in the test suite. Of course, my lack of familiarity with the ICU architecture may mean that the features are covered but I just don't realize it. I'd like to think that small scale and scope of the changes and the fact that they are already included in upstream ICU (I think) and in OpenJDK means that the changes are solid. However, I understand that a regression could be disruptive to wheezy users so I don't want to do something that would unreasonably risk that occurring. Could you (or anyone else) suggest a course of action here? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature