|
18b89885
|
2015-11-03T15:46:29
|
|
Reenable xz support by default
For https://bugzilla.gnome.org/show_bug.cgi?id=757466
problem was introduced by commit f3f86ff465c92c79f834d7b981f3c7274a8bb5c8
for https://bugzilla.gnome.org/show_bug.cgi?id=711026
|
|
f0709e3c
|
2015-11-03T15:31:25
|
|
CVE-2015-8035 Fix XZ compression support loop
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 !)
|
|
a1313a6f
|
2013-11-28T23:21:23
|
|
Fix a bug loading some compressed files
For https://bugzilla.gnome.org/show_bug.cgi?id=712528
Related to https://bugzilla.redhat.com/show_bug.cgi?id=877567
There is a bug in xzlib.c which causes certain compressed XML files to fail to
load correctly. The code in xz_decomp which attempts to verify the checksum
and length of the expanded data fails if the checksum or length at the end of
the file crosses a 1024 byte boundary. It calls gz_next4 to get those two
values. This function uses the stream state in state->zstrm, but calls
xz_avail which uses the state->strm stream info. This causes gz_next4 to
signal a premature EOF if the data it is fetching crosses a 1024 byte boundary.
|
|
63588f47
|
2013-05-10T14:01:46
|
|
Fix a regression in xmlGetDocCompressMode()
The switch to xzlib had for consequence that the compression
level of the input was not gathered anymore in ctxt->input->buf,
then the parser compression flags was left to -1 and propagated
to the resulting document.
Fix the I/O layer to get compression detection in xzlib,
then carry it in the input buffer and the resulting document
This should fix
https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3456
|
|
94431ecb
|
2012-05-15T10:45:05
|
|
Fix various bugs in new code raised by the API checking
* testapi.c: regenerated and covering new APIs
* tree.c: xmlBufferDetach can't work on immutable buffers
* xzlib.c: fix a deallocation error
|
|
9f3cdef0
|
2012-05-15T09:38:13
|
|
Fix a memory leak in the xzlib code
The freeing function wasn't called due to a bogus #ifdef surrounding
value. Also switch the code to use the normal libxml2 allocation and
freeing routines.
|
|
99644927
|
2012-05-07T18:41:42
|
|
fixed a 64bit big endian issue
For https://bugzilla.gnome.org/show_bug.cgi?id=671176
patch fixes a 64bit endian issue, making libxml2 work (again) on ppc64
unsigned int and size_t are differently sized on 64bit.
|
|
72789ef2
|
2012-04-02T17:52:20
|
|
Do not use unsigned but unsigned int
as this breaks the API generator
|
|
adf5ec94
|
2012-01-26T16:56:22
|
|
Cleanups of lzma support
- fix inclusion of the separated file
- use namespaced name for the 4 non-static routines
- add padding after external structures included in-situ
- add new requirement to spec file
- general cleanup of code
|
|
6bdc7743
|
2011-09-19T09:53:20
|
|
move xz/lzma helpers to separate included files
|