- 12 May, 2016 4 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.
-
Christophe Fergeau authored
This makes it more convenient to do builds out of the source dir.
-
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 2 commits
-
-
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 3 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
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.
-
- 29 Jan, 2015 2 commits
-
-
Martin Szulecki authored
-
Martin Szulecki authored
-
- 28 Jan, 2015 6 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
Martin Szulecki authored
-
Martin Szulecki authored
-
Martin Szulecki authored
-
Martin Szulecki authored
-
- 23 Jan, 2015 6 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
-
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!
-
Martin Szulecki authored
-
- 11 Jan, 2015 1 commit
-
-
Aaron Burghardt authored
-
- 22 Oct, 2014 1 commit
-
-
Martin Szulecki authored
If AC_PROG_CXX is used after AC_PROG_CC, it will return "g++" even if no C++ compiler is installed. However, as we need one, testing compiling a program will make configure fail if indeed no C++ compiler is installed.
-
- 14 Oct, 2014 6 commits
-
-
Martin Szulecki authored
-
Martin Szulecki authored
-
Martin Szulecki authored
-
Martin Szulecki authored
-
Martin Szulecki authored
-
Martin Szulecki 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 3 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 26 Sep, 2014 1 commit
-
-
Nikias Bassen authored
-