Обсуждение: More on the libxml2 update situation

So I did a routine software update on my RHEL6 workstation, and noticed
a security update for libxml2 go by.  And guess what: now an XML-enabled
build of Postgres fails regression tests for me, just as previously
discussed in
http://www.postgresql.org/message-id/flat/CAFj8pRA4xJQFGNQCqMCYGx-umgMr3Stt3xFEUw7kBsOiOvGhkA@mail.gmail.com

A little bit of digging shows that the behavior we're unhappy about was
introduced as part of the official patch for CVE-2015-7499.  This means
that, whether or not we can persuade Veillard that it was a bad idea and
he should undo it, the bogus behavior is likely to spread into mainstream
distributions a lot faster than any followup fix will :-(.  Bugfix updates
just don't get accepted as quickly as security updates.

I'm starting to think that maybe we'd better knuckle under and provide
a variant expected file that matches this behavior.  We're likely to be
seeing it in the wild for some time to come.
        regards, tom lane

On Fri, Dec 11, 2015 at 10:55:40AM -0500, Tom Lane wrote:
> So I did a routine software update on my RHEL6 workstation, and noticed
> a security update for libxml2 go by.  And guess what: now an XML-enabled
> build of Postgres fails regression tests for me, just as previously
> discussed in
> http://www.postgresql.org/message-id/flat/CAFj8pRA4xJQFGNQCqMCYGx-umgMr3Stt3xFEUw7kBsOiOvGhkA@mail.gmail.com
> 
> A little bit of digging shows that the behavior we're unhappy about was
> introduced as part of the official patch for CVE-2015-7499.  This means
> that, whether or not we can persuade Veillard that it was a bad idea and
> he should undo it, the bogus behavior is likely to spread into mainstream
> distributions a lot faster than any followup fix will :-(.  Bugfix updates
> just don't get accepted as quickly as security updates.

That settles PostgreSQL's need to accept this variation.

> I'm starting to think that maybe we'd better knuckle under and provide
> a variant expected file that matches this behavior.  We're likely to be
> seeing it in the wild for some time to come.

I would look at handling this by suppressing the exact error message from the
output.  Route affected tests through a wrapper function:

SELECT expect_errdetail($$INSERT INTO xmltest VALUES (3, '<wrong')$$,   E'^line 1: Couldn't find end of Start Tag wrong
line1\n');
 

A variant expected output would be okay, though.

Noah Misch <noah@leadboat.com> writes:
> On Fri, Dec 11, 2015 at 10:55:40AM -0500, Tom Lane wrote:
>> I'm starting to think that maybe we'd better knuckle under and provide
>> a variant expected file that matches this behavior.  We're likely to be
>> seeing it in the wild for some time to come.

> I would look at handling this by suppressing the exact error message from the
> output.

I had actually thought a little bit about whether we could put back the
missing output, along the lines of "if it's a syntax-type error and no
error cursor was supplied, assume we should put a cursor at end of input".
It might be worth pursuing if Veillard indicates an unwillingness to
change libxml2 going forward, because a syntax error with no location
can be pretty unfriendly.  But I'll wait to see some response from him
before expending a lot of energy here.

> A variant expected output would be okay, though.

I pushed a set of those an hour ago.  I hope it's just a short-term
hack, but we'll see.  In any case there were now two buildfarm critters
failing, reinforcing the idea that this behavior is spreading.
        regards, tom lane