Kevin Grittner <kgrittn@gmail.com> writes:
> On Mon, Dec 14, 2015 at 10:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So at this point I'm guessing that Ubuntu has shipped an update that
>> includes the patch Pavel Raiskup suggested in
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1286692#c4
>>
>> which would fix the lack of error cursors at EOF, but it would not affect
>> any larger change such as stopping after the first detected error.
>>
>> If you can confirm that, then we'll need to decide what to do about it.
> I've been looking at this diff, which seems to represent the ubuntu
> libxml2 changes of today, and it seems rather different to what I
> see in the Red Hat discussion. In particular, I see no changes to
> error.c. I haven't really figured the cause of the discrepancy
> yet, but figured I would pass along the diff link.
> http://launchpadlibrarian.net/229976362/libxml2_2.9.1%2Bdfsg1-3ubuntu4.5_2.9.1%2Bdfsg1-3ubuntu4.6.diff.gz
Hmm. What it looks like is that Ubuntu cherry-picked the libxml2 commit
that added xmlHaltParser(), but *not* the follow-on commit that changed
the behavior of xmlParserPrintFileContextInternal(). So that would
probably explain the behavior you're seeing ... though it also raises
the question of whether they've left themselves vulnerable to a null
pointer dereference in xmlParserPrintFileContextInternal(). It's not
clear to me whether that second commit is properly part of the CVE
response or not. But it's Veillard's patch, and he included it in
Red Hat's libxml2 security update, so an informed guess would be "yes".
Regardless of that, it now seems likely to me that what you're seeing
is what the output will look like if the no-error-cursor-at-EOF problem
gets fixed, which is what we're hoping will happen. So we had better
change the regression tests to accept this behavior too.
As I said, my inclination is to remove the SELECT xmlparse(document '')
test case altogether. The following test SELECT xmlparse(document ' ')
seems like it provides as much useful coverage as we need for that,
and its output doesn't depend on whether libxml2 continues parsing
after the first error.
regards, tom lane