Update libexpat to 2.1.0

Update libexpat to 2.1.0
    
Current third_party/expat library is version 2.0.1 (June 2007). There's a more recent version available, 2.1.0 (March 2012). This latest version fixes several bugs like memory leaks and parsing crashes among other things.

Chromium thir_party/expat library contained one downstream patch which fixed some issues in Windows. This patch is also applied in this upgrade.

BUG=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=250770

[Diego Pino, 2013-11-12 08:49:28]

Could you review this CL?

[rlarocque, 2013-12-17 21:35:35]

Sorry for the slow review.  It's taken a little while for us to figure out who
actually owns the code and who might be affected by the update.  Those
discussions are still in progress, so I can't guarantee yet that we'll be able
to accept it.

In the meantime, I did look at your patch.  I've got one small comment, but
otherwise I think it looks fine.

I can't find your name on the external contributors list, though your company
and many of your co-workers are listed.  Apparently, we won't be able to accept
your patch unless your name and e-mail address is on the list.  I don't know the
procedure for adding corporate contributors to the list.  Maybe your co-workers
know how that works?  If they can't help, then we should ask mal@chromium.org.

See:
http://www.chromium.org/developers/contributing-code/external-contributor-che...

https://codereview.chromium.org/68713003/diff/1/third_party/expat/files/lib/x...
File third_party/expat/files/lib/xmltok_impl.c (right):

https://codereview.chromium.org/68713003/diff/1/third_party/expat/files/lib/x...
third_party/expat/files/lib/xmltok_impl.c:1751: if (end - ptr < n) { \
It seems we added this early return statement to fix a bug.  The change on line
1747 is the upstream fix to that same bug.  I think we can undo our local
modification as we pull in the upstream fix.  

See http://sourceforge.net/p/expat/bugs/464/.

[Diego Pino, 2013-12-26 21:00:53]

On 2013/12/17 21:35:35, rlarocque wrote:
> Sorry for the slow review.  It's taken a little while for us to figure out who
> actually owns the code and who might be affected by the update.  Those
> discussions are still in progress, so I can't guarantee yet that we'll be able
> to accept it.
> 

np

> In the meantime, I did look at your patch.  I've got one small comment, but
> otherwise I think it looks fine.
> 
> I can't find your name on the external contributors list, though your company
> and many of your co-workers are listed.  Apparently, we won't be able to
accept
> your patch unless your name and e-mail address is on the list.  I don't know
the
> procedure for adding corporate contributors to the list.  Maybe your
co-workers
> know how that works?  If they can't help, then we should ask
mailto:mal@chromium.org.
> 

Yes it's true. Some of my colleagues have already signed the CLA although it was
not my case. I was not aware of this. I asked a colleague and we are going to
send a new request to Google to add me to the CLA (plus some other colleagues).
I guess that once the CLA procedure is completed we can go ahead with the patch.

I may ping you as soon as I got news from the status of the CLA.

>
https://codereview.chromium.org/68713003/diff/1/third_party/expat/files/lib/x...
> third_party/expat/files/lib/xmltok_impl.c:1751: if (end - ptr < n) { \
> It seems we added this early return statement to fix a bug.  The change on
line
> 1747 is the upstream fix to that same bug.  I think we can undo our local
> modification as we pull in the upstream fix.  
> 

Fixed in the new patch.

[rlarocque, 2014-01-02 19:35:20]

On 2013/12/26 21:00:53, Diego Pino wrote:
> On 2013/12/17 21:35:35, rlarocque wrote:
> > Sorry for the slow review.  It's taken a little while for us to figure out
who
> > actually owns the code and who might be affected by the update.  Those
> > discussions are still in progress, so I can't guarantee yet that we'll be
able
> > to accept it.
> > 
> 
> np
> 
> > In the meantime, I did look at your patch.  I've got one small comment, but
> > otherwise I think it looks fine.
> > 
> > I can't find your name on the external contributors list, though your
company
> > and many of your co-workers are listed.  Apparently, we won't be able to
> accept
> > your patch unless your name and e-mail address is on the list.  I don't know
> the
> > procedure for adding corporate contributors to the list.  Maybe your
> co-workers
> > know how that works?  If they can't help, then we should ask
> mailto:mal@chromium.org.
> > 
> 
> Yes it's true. Some of my colleagues have already signed the CLA although it
was
> not my case. I was not aware of this. I asked a colleague and we are going to
> send a new request to Google to add me to the CLA (plus some other
colleagues).
> I guess that once the CLA procedure is completed we can go ahead with the
patch.
> 
> I may ping you as soon as I got news from the status of the CLA.
> 
> >
>
https://codereview.chromium.org/68713003/diff/1/third_party/expat/files/lib/x...
> > third_party/expat/files/lib/xmltok_impl.c:1751: if (end - ptr < n) { \
> > It seems we added this early return statement to fix a bug.  The change on
> line
> > 1747 is the upstream fix to that same bug.  I think we can undo our local
> > modification as we pull in the upstream fix.  
> > 
> 
> Fixed in the new patch.

There were no objections to upgrading this library.  The content of your updated
patch looks good.  Let me know when the CLA issue is resolved and I'll approve
this commit.

[Diego Pino, 2014-01-31 10:12:41]

On 2014/01/02 19:35:20, rlarocque wrote:

> 
> There were no objections to upgrading this library.  The content of your
updated
> patch looks good.  Let me know when the CLA issue is resolved and I'll approve
> this commit.

About the CLA, we sent a new request to Google adding me and some more
colleagues to the CLA on 20th Dec. Previous requests didn't last long, so we
pinged Google again two weeks later but no response yet. Up to date we're still
waiting :/ I will keep you inform if we receive any news.

[Diego Pino, 2014-02-04 19:33:39]

On 2014/01/31 10:12:41, Diego Pino wrote:
> On 2014/01/02 19:35:20, rlarocque wrote:
> 
> > 
> > There were no objections to upgrading this library.  The content of your
> updated
> > patch looks good.  Let me know when the CLA issue is resolved and I'll
approve
> > this commit.
> 
> About the CLA, we sent a new request to Google adding me and some more
> colleagues to the CLA on 20th Dec. Previous requests didn't last long, so we
> pinged Google again two weeks later but no response yet. Up to date we're
still
> waiting :/ I will keep you inform if we receive any news.

Done, today we got news from Google that I have been successfully added to the
CLA :)

[rlarocque, 2014-02-04 19:50:07]

On 2014/02/04 19:33:39, Diego Pino wrote:
> On 2014/01/31 10:12:41, Diego Pino wrote:
> > On 2014/01/02 19:35:20, rlarocque wrote:
> > 
> > > 
> > > There were no objections to upgrading this library.  The content of your
> > updated
> > > patch looks good.  Let me know when the CLA issue is resolved and I'll
> approve
> > > this commit.
> > 
> > About the CLA, we sent a new request to Google adding me and some more
> > colleagues to the CLA on 20th Dec. Previous requests didn't last long, so we
> > pinged Google again two weeks later but no response yet. Up to date we're
> still
> > waiting :/ I will keep you inform if we receive any news.
> 
> Done, today we got news from Google that I have been successfully added to the
> CLA :)

Glad to hear it.

You should update your commit message.  I think we only have one downstream
patch now.  Otherwise, LGTM.

I was going to kick off some trybots for you, but the web site won't let me
because this issue is read only.  I've never seen that before.  Let me know if
you're having trouble committing, too.  We might need to move this patch to a
separate upload.

[rlarocque, 2014-02-04 21:28:21]

On 2014/02/04 19:50:07, rlarocque wrote:
> On 2014/02/04 19:33:39, Diego Pino wrote:
> > On 2014/01/31 10:12:41, Diego Pino wrote:
> > > On 2014/01/02 19:35:20, rlarocque wrote:
> > > 
> > > > 
> > > > There were no objections to upgrading this library.  The content of your
> > > updated
> > > > patch looks good.  Let me know when the CLA issue is resolved and I'll
> > approve
> > > > this commit.
> > > 
> > > About the CLA, we sent a new request to Google adding me and some more
> > > colleagues to the CLA on 20th Dec. Previous requests didn't last long, so
we
> > > pinged Google again two weeks later but no response yet. Up to date we're
> > still
> > > waiting :/ I will keep you inform if we receive any news.
> > 
> > Done, today we got news from Google that I have been successfully added to
the
> > CLA :)
> 
> Glad to hear it.
> 
> You should update your commit message.  I think we only have one downstream
> patch now.  Otherwise, LGTM.
> 
> I was going to kick off some trybots for you, but the web site won't let me
> because this issue is read only.  I've never seen that before.  Let me know if
> you're having trouble committing, too.  We might need to move this patch to a
> separate upload.

I'm not sure what changed, but the trybots are working now.  I've started a few
of them to try out this change on a few different platforms.  

Also, we'll need to get an approval from an OWNER of third_party before
committing this.  I'll add another review for that.

[rlarocque, 2014-02-04 21:28:42]

cpu@chromium.org: Please review changes in third_party.

[cpu_(ooo_6.6-7.5), 2014-02-04 22:10:58]

lgtm

cevans: can you security rubber stamp this?

[Chris Evans, 2014-02-05 01:36:12]

https://codereview.chromium.org/68713003/diff/110001/third_party/expat/README...
File third_party/expat/README.chromium (right):

https://codereview.chromium.org/68713003/diff/110001/third_party/expat/README...
third_party/expat/README.chromium:7: Security Critical: yes
What's the rationale for this addition? Do we use expat for parsing hostile XML?
I thought the Chrome browser is pretty much settled on libxml for that?

[Diego Pino, 2014-02-07 07:59:05]

On 2014/02/05 01:36:12, Chris Evans wrote:
>
https://codereview.chromium.org/68713003/diff/110001/third_party/expat/README...
> File third_party/expat/README.chromium (right):
> 
>
https://codereview.chromium.org/68713003/diff/110001/third_party/expat/README...
> third_party/expat/README.chromium:7: Security Critical: yes
> What's the rationale for this addition? Do we use expat for parsing hostile
XML?
> I thought the Chrome browser is pretty much settled on libxml for that?

Fixed Security Critial = no and updated commit message as suggested by
rlarocque.

[Diego Pino, 2014-02-12 17:16:24]

The CQ bit was checked by dpino@igalia.com

[Diego Pino, 2014-02-12 17:16:32]

The CQ bit was unchecked by dpino@igalia.com

[Diego Pino, 2014-02-12 17:16:33]

The CQ bit was checked by dpino@igalia.com

[commit-bot: I haz the power, 2014-02-12 17:17:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dpino@igalia.com/68713003/260001

[commit-bot: I haz the power, 2014-02-12 19:09:51]

Change committed as 250770