[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: icu package and debdiff [new contributor, first attempt]

(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):


> 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?



Roberto C. Sánchez

Attachment: signature.asc
Description: Digital signature

Reply to: