IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For https://bugzilla.gnome.org/show_bug.cgi?id=759671
when the end of the internal subset isn't properly detected
xmlParseInternalSubset should just return instead of trying
to process input further.
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
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
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
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
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.
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 !)
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
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
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
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.
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.
- 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.
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.
If the context node is an attribute, the attribute itself is on the
descendant-or-self axis. The principal node type of this axis is element,
so the only node test that can return the attribute is "node()". In other
words, "@attr/descendant-or-self::node()" is equivalent to "@attr".
This matches the behavior of Saxon-CE.
For https://bugzilla.gnome.org/show_bug.cgi?id=737851
Unfortunately this change has introduced a problem which results in
occasional hangs on Windows when running multi-threaded on a multi-core
host.
When locking the xmlRMutex the count field is increment inside the
critical section but when unlocking the count field is decremented
outside the critical section. The increment/decrement is not atomic so
this can result in the count field being updated incorrectly.
The solution is to change xmlRMutexUnlock to decrement the count field
before leaving the critical section rather than after.
See http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/
We use a "runLen" array of size 128, so it should be nearly impossible
to have our implementation overflow.
But in any case, the fix is relatively simple -- checking two extra
conditions in the invariant calculation.
I also took this opportunity to remove some redundancy in the
left/right merge logic in the invariant loop.
For https://bugzilla.gnome.org/show_bug.cgi?id=744980
The error handling of Conditional Section also need to be
straightened as the structure of the document can't be
guessed on a failure there and it's better to stop parsing
as further errors are likely to be irrelevant.
For https://bugzilla.gnome.org/show_bug.cgi?id=744980
There are times, like on unterminated entities that it's preferable to
stop parsing, even if that means less error reporting. Entities are
feeding the parser on further processing, and if they are ill defined
then it's possible to get the parser to bug. Also do the same on
Conditional Sections if the input is broken, as the structure of
the document can't be guessed.
Fixes bug #704908
The declarations of pthread functions, used to generate weak references
to them, fail to suppress macros. Thus, if any pthread function has
been provided as a macro, compiling threads.c will fail.
This breaks on musl libc, which defines pthread_equal as a macro (in
addition to providing the function, as required).
Prevent the declarations for e.g. musl libc by refining the condition.
The idea for this solution was borrowed from the alpine linux guys, see
http://git.alpinelinux.org/cgit/aports/tree/main/libxml2/libxml2-pthread.patch
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
