More on the libxml2 update situation

Started by Tom Laneabout 10 years ago3 messages
#1Tom Lane
tgl@sss.pgh.pa.us

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
/messages/by-id/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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Noah Misch
noah@leadboat.com
In reply to: Tom Lane (#1)
Re: More on the libxml2 update situation

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
/messages/by-id/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 line 1\n');

A variant expected output would be okay, though.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Noah Misch (#2)
Re: More on the libxml2 update situation

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers