- 29 Jun, 2016 1 commit
-
-
Nikias Bassen authored
Without this check, e.g. the values -1 and 18446744073709551615 would yield in a match, since the comparison will just compare the uint64_t values. However, any value >= 9223372036854775808 and <= 18446744073709551615 is stored as a 128 bit value in binary plist format to make sure it is recognized as an unsigned value. We store it internally as a uint64_t value, but we set the size to 16 vs. 8 accordingly; so this commit will make sure the binary plist optimization will not re-use matching uint64_t values of actually mismatching signed/unsigned values.
-
- 12 May, 2016 3 commits
-
-
Christophe Fergeau authored
Rather than having everyone reimplement binary/XML plist detection by looking at the first bytes of the plist content, it's better to do this detection in libplist and hide that internal detail from library users.
-
Christophe Fergeau authored
It can be useful if one needs to know what type of plist a memory buffer contains.
-
Nikias Bassen authored
Using a better hashing algorithm and a larger hash table the conversion is A LOT faster when processing large plists. Thanks to Xiao Deng for reporting this issue and suggesting a fix.
-
- 20 Apr, 2016 1 commit
-
-
Frederik Carlier authored
-
- 07 Dec, 2015 1 commit
-
-
Aaron Burghardt authored
Fixes libimobiledevice/libplist#50.
-
- 13 Nov, 2015 1 commit
-
-
Nikias Bassen authored
-
- 05 Feb, 2015 1 commit
-
-
Nikias Bassen authored
-
- 31 Jan, 2015 2 commits
-
-
Nikias Bassen authored
When parsing binary plists with BPLIST_DICT or BPLIST_ARRAY nodes that are referenced multiple times in a particular file, a buffer was allocated that was not used, and also not freed, thus causing memory leaks.
-
Nikias Bassen authored
Given a specifically ordered binary plist the function plist_from_bin() would free BPLIST_DICT or BPLIST_ARRAY raw node data that is still required for parsing of following nodes. This commit addresses this issues by moving the memory free to the end of the parsing process.
-
- 28 Jan, 2015 1 commit
-
-
Martin Szulecki authored
-
- 23 Jan, 2015 3 commits
-
-
Martin Szulecki authored
This is actually considered bad practice. However, it appears this memory leak is otherwise not possible to fix due to a design flaw in how libxml2 handles the lifecycle of it's XML parser. We'll let the community test this in production now and decide. In our tests this change had no drawbacks except fixing the last known memory leak in libplist.
-
Martin Szulecki authored
-
Martin Szulecki authored
By using a specifically crafted XML file an attacker could use plistutil to issue a GET request to an arbitrary URL or disclose a local file. The crafted XML file would be using a custom DTD with an external entity reference pointing to the file. Practical abuse is limited but let's still fix it nevertheless. Related to CVE-2013-0339 for libxml2 and CWE-827. Reported by Loïc Bénis from calypt.com. Thanks!
-
- 11 Jan, 2015 1 commit
-
-
Aaron Burghardt authored
-
- 09 Oct, 2014 1 commit
-
-
Martin Szulecki authored
The parsing logic for binary dictionaries wrongly enforced the key type even on nodes that were already parsed as value nodes. This caused the resulting plist_t node tree to have key nodes instead of value nodes within dictionaries for some valid binary plists. This commit should also generally fixes parsing of binary plist files which use an efficient dictionary reference table.
-
- 03 Oct, 2014 2 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 23 Sep, 2014 1 commit
-
-
Nikias Bassen authored
-
- 19 Sep, 2014 3 commits
-
-
Nikias Bassen authored
-
Aaron Burghardt authored
-
Aaron Burghardt authored
Change Clone() to be const, which required constructors with const references and a const GetValue().
-
- 25 Aug, 2014 1 commit
-
-
Aaron Burghardt authored
-
- 05 Aug, 2014 1 commit
-
-
Nikias Bassen authored
-
- 27 May, 2014 1 commit
-
-
Martin Szulecki authored
-
- 23 May, 2014 1 commit
-
-
Nikias Bassen authored
-
- 22 May, 2014 2 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 21 May, 2014 1 commit
-
-
Nikias Bassen authored
-
- 20 May, 2014 2 commits
-
-
Nikias Bassen authored
-
Martin Szulecki authored
-
- 18 May, 2014 2 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 02 Apr, 2014 1 commit
-
-
Nikias Bassen authored
-
- 01 Apr, 2014 1 commit
-
-
Nikias Bassen authored
-
- 29 Mar, 2014 1 commit
-
-
Chow Loong Jin authored
On debian-mips, neither __LITTLE_ENDIAN__ nor __BIG_ENDIAN__ are defined anywhere, so PLIST_BYTE_ORDER defaults to PLIST_LITTLE_ENDIAN when it should really be PLIST_BIG_ENDIAN on this architecture. This fixes issue #13.
-
- 28 Mar, 2014 1 commit
-
-
Christophe Fergeau authored
On my machine, parallel builds fail with: make[2]: Entering directory `/home/teuf/hack/libplist/src' CCLD libplist.la make[2]: *** No rule to make target `../src/libplist.la', needed by `libplist++.la'. Stop. If $(top_builddir)/src/libplist.la does not exist yet when trying to link libplist++.la, automake/make will not realize the $(top_builddir)/src/libplist.la dependency is the same as the libplist.la target, and will thus be unable to generate $(top_builddir)/src/libplist.la. Using the libplist.la instead fixes this issue. I've checked that srcdir!=builddir and make distcheck still pass after this change.
-
- 19 Mar, 2014 2 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 13 Feb, 2014 1 commit
-
-
Martin Szulecki authored
-