* configure.ac: updated
* doc/*: regenerated

Hugh Davenport authored Nov 20, 2015 and Daniel Veillard committed Nov 20, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=756372
Error in the code pointing to the codepoint in the stack for the
current char value instead of the pointer in the input that the SAX
callback expects
Reported and fixed by Hugh Davenport

For https://bugzilla.gnome.org/show_bug.cgi?id=756525
handle properly the case where we popped out of the current entity
while processing a start tag
Reported by Kostya Serebryany @ Google

This slightly modifies the output of 754946 in regression tests

sometimes the entity could have a lenght of 0, i.e. it wasn't
parsed or used yet, and we ended up with an incoherent input state

Next can switch the parser back to XML_PARSER_EOF state, we
need to consider those in loops consuming input

the current pointer to the input has to be between the base and end
if not stop everything we have an internal state error.

Which now happens more frequently du to xmlHaltParser use

Unify the various place where either xmlStopParser was called
(which resets the error as a side effect) and places where we
used ctxt->instate = XML_PARSER_EOF to stop further processing

The problem is doing it in a consistent and safe fashion
It's more complex than just setting ctxt->instate = XML_PARSER_EOF
Update the public function to reuse that new internal routine

David Drysdale authored Nov 20, 2015 and Daniel Veillard committed Nov 20, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=756733
It is one case where the code in place to detect entities expansions
failed to exit when the situation was detected, leading to DoS
Problem reported by Kostya Serebryany @ Google
Patch provided by David Drysdale @ Google

David Drysdale authored Nov 20, 2015 and Daniel Veillard committed Nov 20, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=756528
It was possible to hit a negative offset in the name indexing
used to randomize the dictionary key generation
Reported and fix provided by David Drysdale @ Google

I had used it in contexts where that information ought to be preserved

For https://bugzilla.gnome.org/show_bug.cgi?id=756527
and was also raised by Chromium team in the past

When we hit a convwersion failure when switching encoding
it is bestter to stop parsing there, this was treated as a
fatal error but the parser was continuing to process to extract
more errors, unfortunately that makes little sense as the data
is obviously corrupt and can potentially lead to unexpected behaviour.

Hugh Davenport authored Nov 03, 2015 and Daniel Veillard committed Nov 03, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=756263

One place where ctxt->instate == XML_PARSER_EOF whic was set up
by entity detection issues doesn't get noticed, and even overrided

For https://bugzilla.gnome.org/show_bug.cgi?id=757466

problem was introduced by commit f3f86ff4
for https://bugzilla.gnome.org/show_bug.cgi?id=711026

For https://bugzilla.gnome.org/show_bug.cgi?id=757466
DoS when parsing specially crafted XML document if XZ support
is compiled in (which wasn't the case for 2.9.2 and master since
Nov 2013, fixed in next commit !)

For https://bugzilla.gnome.org/show_bug.cgi?id=746048
The HTML parser was too optimistic when processing comments and
didn't check for the end of the stream on the first 2 characters

an off by one mistake in the change, led to error on correct
document where the end of the included entity was exactly
the end of the conditional section, leading to regtest failure

Fabien Degomme authored Oct 23, 2015 and Daniel Veillard committed Oct 23, 2015

Obviously it operates on the output not the input

Which happen after the previous fix to
https://bugzilla.gnome.org/show_bug.cgi?id=756456

But stopping the parser and exiting we didn't pop the intermediary entities
and doing the SKIP there applies on an input which may be too small

Gaurav authored Sep 30, 2015 and Daniel Veillard committed Sep 30, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=755857

a case where we check for NULL but not everywhere

For https://bugzilla.gnome.org/show_bug.cgi?id=754947

The checking function was returning incorrect args in some cases
Adds the test to teh reg suite and fix one of the existing test output

For https://bugzilla.gnome.org/show_bug.cgi?id=754946

When hitting the end of the current input buffer while parsing
a name we could end up loosing the beginning of the name, which
led to various issues.

For https://bugzilla.gnome.org/show_bug.cgi?id=737840
the fix for 724903 introduced a regression on external entities carrying
IDs, revert that patch in part and add a specific test to avoid readding it

Commit ba58f23c broke comparison of nodes from different documents.
Thanks to Olli Pottonen for the report.

query string need to be escaped before being displayed back

As pointed by Christian Schoenebeck <schoenebeck@crudebyte.com>
on the list and based on some of his early patches, this preserve
content when unescaped opening angle brackets are not escaped in
textual content like:
  <p>  a < b </p>
  <p> a <0 </p>
  <p> a <=0 </p>

while still reporting the error.

Scott Graham authored Jun 30, 2015 and Daniel Veillard committed Jun 30, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=751679

Also added a few newline cleanups

For https://bugzilla.gnome.org/show_bug.cgi?id=751631

If we fail conversing the current input stream while
processing the encoding declaration of the XMLDecl
then it's safer to just abort there and not try to
report further errors.

For https://bugzilla.gnome.org/show_bug.cgi?id=751603

If the string is not properly terminated do not try to convert
to the given encoding.

Clang doesn't have perfect feature compatibility with GCC,
unfortunately.

https://bugzilla.gnome.org/show_bug.cgi?id=747870

Patrick Monnerat authored Apr 16, 2015 and Daniel Veillard committed Apr 16, 2015

    - A typo caused an undefined symbol reference.
    - A structure field name did not match the corresponding C name due to a typo.
    - Some structured fields were not properly aligned.
    - The long/ulong types were wrongly mapped to 64-bit types.
    - A typo in a /include directive caused a compilation error.
    - Doc files copy now converts from UTF-8 and split long lines.
    - Adjust /include file name mapping translation for proper prefix handling.

One of the operation on the reader could resolve entities
leading to the classic expansion issue. Make sure the
buffer used for xmlreader operation is bounded.
Introduce a new allocation type for the buffers for this effect.

Martin von Gagern authored Apr 13, 2015 and Daniel Veillard committed Apr 13, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=747437
just use the mutex to protect access to those variables

Shaun McCance authored Apr 03, 2015 and Daniel Veillard committed Apr 03, 2015

For https://bugzilla.gnome.org/show_bug.cgi?id=747301

Use simple HTML5 DOCTYPE for about:legacy-compat

HTML5 uses a DOCTYPE without a PUBLIC or SYSTEM identifier. It looks
like this:

<!DOCTYPE html>

I can't use XSLT to output this, because to get a DOCTYPE I have to
provide a PUBLIC or SYSTEM identifier. Luckily, the standards folks
recognized this and provided this semantically equivalent form for the
HTML DOCTYPE:

<!DOCTYPE html SYSTEM "about:legacy-compat">

But people don't like seeing the "legacy" identifier in their output.
They'd rather see the shiny new DOCTYPE. Since we know that
about:legacy-compat is defined by the W3C to be semantically equivalent
to the sans-SYSTEM DOCTYPE, we could just special-case it in the HTML
serializer in libxml2. So if you set the SYSTEM identifier to
"about:legacy-compat", you get an HTML5 short-form DOCTYPE.

For https://bugzilla.gnome.org/show_bug.cgi?id=565219

The code was imply missing even if simple, added a few regression
tests.

Make sure root nodes are sorted before other nodes.