kc3-lang/zlib/contrib
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
51b7f2ab | 2024-01-22 10:14:31 | zlib 1.3.1 | |
|
c06dfecb | 2024-01-21 09:24:10 | Use Makefile compiler for minizip-test target. | |
 |
fe41d189 | 2023-08-06 13:56:45 | Correct typos in source code. | |
 |
14a5f8f2 | 2024-01-17 14:46:18 | Neutralize zip file traversal attacks in miniunz. Archive formats such as .zip files are generally susceptible to so-called "traversal attacks". This allows an attacker to craft an archive that writes to unexpected locations of the file system (e.g., /etc/shadow) if an unspecting root user were to unpack a malicious archive. This patch neutralizes absolute paths such as /tmp/moo and deeply relative paths such as dummy/../../../../../../../../../../tmp/moo The Debian project requested CVE-2014-9485 be allocated for the first identified weakness. The fix was incomplete, resulting in a revised patch applied here. Since there wasn't an updated version released by Debian with the incomplete fix, I suggest we use this CVE to identify both issues. Link: https://security.snyk.io/research/zip-slip-vulnerability Link: https://bugs.debian.org/774321 Link: https://bugs.debian.org/776831 Link: https://nvd.nist.gov/vuln/detail/CVE-2014-9485 Reported-by: Jakub Wilk <jwilk@debian.org> Fixed-by: Michael Gilbert <mgilbert@debian.org> | |
 |
01155ccc | 2023-12-02 16:56:47 | Fix random typos over several source and text files. | |
 |
190168cc | 2023-12-11 11:47:43 | Correct case of MSDOS in contrib/minizip/miniunz.c. | |
|
762cf49e | 2023-12-11 12:01:52 | Refer to correct function in contrib/minizip/unzip.c comment. | |
 |
643e17b7 | 2023-11-14 16:23:02 | Correct repeated words in source file comments and a readme. | |
|
15c45adb | 2023-11-07 15:46:41 | Fix decision on the emission of Zip64 end records in minizip. The appnote says that if the number of entries in the end record is 0xffff, then the actual number of entries will be found in the Zip64 end record. Therefore if the number of entries is equal to 0xffff, it can't be in the end record by itself, since that is an instruction to get the number from the Zip64 end record. This code would just store 0xffff in the end record in that case, not making a Zip64 end record. This commit fixes that. | |
 |
88e50f17 | 2016-11-15 21:04:58 | Update miniunz version. |