selmf / unarr Goto Github PK

View Code? Open in Web Editor NEW

65.0 5.0 12.0 521 KB

A decompression library for rar, tar, zip and 7z archives

License: GNU Lesser General Public License v3.0

Makefile 0.26% C 97.75% CMake 1.99%

rar tar zip decompression-library cbr cbz cbt 7z cb7

unarr's People

Contributors

Stargazers

Watchers

Forkers

pombredanne tim77 freeblow comicfans coolaj86 srinivas32 liuxiang88 hanjianju mastercoms layerfsd simonen64 peterlintang

unarr's Issues

add new release to fix includedir and libdir in libunarr.pc

build of version 1.1.0.beta1 fails in nix with

Broken paths found in a .pc file! /nix/store/svpsz4vq1m3yzb1fj24sgfwwr6z1mh31-unarr-1.1.0.beta1/lib/pkgconfig/libunarr.pc
The following lines have issues (specifically '//' in paths).
2:includedir=${prefix}//nix/store/svpsz4vq1m3yzb1fj24sgfwwr6z1mh31-unarr-1.1.0.beta1/include
3:libdir=${prefix}//nix/store/svpsz4vq1m3yzb1fj24sgfwwr6z1mh31-unarr-1.1.0.beta1/lib
It is very likely that paths are being joined improperly.
ex: "${prefix}/@CMAKE_INSTALL_LIBDIR@" should be "@CMAKE_INSTALL_FULL_LIBDIR@"
Please see https://github.com/NixOS/nixpkgs/issues/144170 for more details.

blame pkg-config.pc.cmake

unarr/pkg-config.pc.cmake

Lines 2 to 3 in ab2cac2

 includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@ 

 libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@

fixed in eb4f17c

related #23

unarr.nix

{ lib
, stdenv
, fetchFromGitHub
, cmake
}:

stdenv.mkDerivation rec {
  pname = "unarr";
  #version = "1.0.1"; # Broken paths found in a .pc file
  #version = "1.1.0.beta1"; # Broken paths found in a .pc file
  version = "1.1.0-unstable-2022-10-08";

  src = fetchFromGitHub {
    owner = "selmf";
    repo = "unarr";
    #rev = "v${version}";
    #hash = "sha256-H9Y6cgVZxU4EcY/6USqtUdlAyM9fvJfeKIkFYLjyJJk="; # 1.0.1
    #hash = "sha256-ic+K//sTSiAzUv1saTbJK2FQe65/GAw4w4QxW9OQ0lk="; # 1.1.0.beta1
    # fix: Broken paths found in a .pc file
    # /nix/store/1mphn2l0mb2bcrxn90mkmkg1kpl2nyb8-unarr-1.0.1/lib/pkgconfig/libunarr.pc
    # The following lines have issues (specifically '//' in paths).
    # 2:includedir=${prefix}//nix/store/1mphn2l0mb2bcrxn90mkmkg1kpl2nyb8-unarr-1.0.1/include
    # 3:libdir=${prefix}//nix/store/1mphn2l0mb2bcrxn90mkmkg1kpl2nyb8-unarr-1.0.1/lib
    rev = "569ffdb063ce8a76ab069444af175e5953d90c93";
    hash = "sha256-O6P+3NA2dFg8G5hCyQvk0FUP7boPP0P0I/ukRWmWfu8=";
  };

  nativeBuildInputs = [
    cmake
  ];

  meta = with lib; {
    description = "A decompression library for rar, tar, zip and 7z archives";
    homepage = "https://github.com/selmf/unarr";
    changelog = "https://github.com/selmf/unarr/blob/${src.rev}/CHANGELOG.md";
    license = with licenses; [ ];
    maintainers = with maintainers; [ ];
  };
}

Please release a new version so a version with 7zip support can get packaged

please release a new version with the new 7zip support so distributions can pick it up as they don't like packaging from git snapshots unless they have to

pkg-config file is broken when CMAKE_INSTALL_{INCLUDE,LIB}DIR is absolute

As per title: pkg-config.pc.cmake has

prefix=@CMAKE_INSTALL_PREFIX@
includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@

and so can’t handle absolute paths in CMAKE_INSTALL_{INCLUDE,LIB}DIR. This leads to broken .pc files on NixOS in particular.

See “Concatenating paths when building pkg-config files” for a thorough discussion of the problem and a suggested fix, or KDE’s extra-cmake-modules for a simpler approach.

When un7zip size of 100GB.7z and 10GB.7z files report an error ：'unarr: No valid RAR, ZIP, 7Z or TAR archive'

Use dd create 1GB 10GB 100GB file
dd if=/dev/random of=data1GB.bin bs=40m count=25
dd if=/dev/random of=data10GB.bin bs=400m count=25
dd if=/dev/random of=data100GB.bin bs=4000m count=25
and use command '7z a' archive to data1GB.7z data10GB.7z data100GB.7z
When un7zip size of 100GB.7z and 10GB.7z files report an error ：'unarr: No valid RAR, ZIP, 7Z or TAR archive'
But, un7zip size under 1GB file successfully!!!

Last，I test 2GB / 3GB / 4GB /5GB ,only 2GB file success, and above 2GB file failed!

OS : macOS 12.4
GOVERSION="go1.18.3"

gen2brain/go-unarr#32

1.0.1: no ctest test units

Looks like test/ content is not integrated with cmake/ctest

[tkloczko@devel-g2v x86_64-redhat-linux-gnu]$ ctest -vv
Test project /home/tkloczko/rpmbuild/BUILD/unarr-1.0.1/x86_64-redhat-linux-gnu
No tests were found!!!

Missing `raw` parameter in `x_get_name` calls

I'm getting a compile error on master, where it looks like the recently introduced raw parameter is not passed in the following four calls:

[build] ...\unarr\_7z\_7z.c(78,9): error C2198: '_7z_get_name': too few arguments for call [...\unarr\unarr.vcxproj]
[build]   conv.c
[build]   crc32.c
[build]   stream.c
[build]   unarr.c
[build]   filter-rar.c
[build]   huffman-rar.c
[build]   parse-rar.c
[build]   rar.c
[build] ...\unarr\rar\rar.c(65,21): error C2198: 'rar_get_name': too few arguments for call [...\unarr\unarr.vcxproj]
[build]   uncompress-rar.c
[build]   parse-tar.c
[build]   tar.c
[build] ...\unarr\tar\tar.c(43,9): error C2198: 'tar_get_name': too few arguments for call [...\ext\unarr\unarr.vcxproj]
[build]   parse-zip.c
[build]   uncompress-zip.c
[build]   zip.c
[build] ...\unarr\zip\zip.c(109,9): error C2198: 'zip_get_name': too few arguments for call [...\ext\unarr\unarr.vcxproj]

QtWebApp

Could you please remove the keyword "official" from your fork of my QtWebApp project?

Thank you.

RAR 5.0 support needed

RAR 5.0 format support needed, Your can see example for unpack code in to source tarball unrarsrc-5.7.4.tar.gz (ftp://Anonymous:[email protected]@ftp.rarlabs.com:21/rar/unrarsrc-5.7.4.tar.gz) on FTP RarLabs.com. Starting on Rar/WinRAR v5.00 (22.08.2013 year) RAR5 is default compression format fo rar archives (see WhatsNew.txt for details and have different in to RAR 2.9 (used up to Rar v2.5 - Rar v4.20 as default) format.

Please, update unarr library for support this Rar archive default format.

API limits the maximum archive entry size on 32bit systems

The current API, namely the functions: ar_entry_get_size and ar_entry_uncompress use size_t in their signature, which limits the maximum size of archive entries on 32bit systems. Would you consider changing the API to use a fixed-width 64bit unsigned integer type, such that both 32bit and 64bit systems would be able to handle large archive entries?

allocate very big memory for some invalid input

during fuzzer test, I've found unarr may try to allocate very big memory (malloc(4294967296)) for some invalid input, the code path goes as

#7 0x55f8e1e98949 in malloc (/home/wangxinyu/unarr/fuz/test/fuzzer+0x132949)
#8 0x7fe3a3744dc0 in gLzma_Alloc /home/wangxinyu/unarr/fuz/../zip/uncompress-zip.c:284:78
#9 0x7fe3a375155c in LzmaDec_Allocate /home/wangxinyu/unarr/fuz/../lzmasdk/LzmaDec.c:1150:22
#10 0x7fe3a3743334 in zip_uncompress_data_lzma /home/wangxinyu/unarr/fuz/../zip/uncompress-zip.c:314:15
#11 0x7fe3a373fd35 in zip_uncompress_part /home/wangxinyu/unarr/fuz/../zip/uncompress-zip.c:529:17
#12 0x7fe3a3747105 in zip_uncompress /home/wangxinyu/unarr/fuz/../zip/zip.c:152:14
#13 0x7fe3a36d2779 in ar_entry_uncompress /home/wangxinyu/unarr/fuz/../common/unarr.c:85:12

an example input as follows (base64 coded):

AAgAAAAAAAAACv0A5PxQSwMEHBy8BA4AADpSEABSEChQAAAAAAADBBwAAAAAHAo/SwMAHFIEA7wJ
ABAoAAAAAAAcAChSTApQSwAqAHEAAPj/////r7T/CgAATApQSwUGAAIA/zJDBl07ACEAAAAAAAAA
BLwJHgADAANSEAADAAAAAAAAABJAAAAK/eQA/FBLAwQcHLwEDgAAAFIAAABS

1.0.1: version problems.

While version 1.0.1 is, well, 1.0.1 the CMakelists.txt file contains the definition

project(unarr VERSION 1.0.0 LANGUAGES C)

As a consequence, the pkgconfig file uses a 1.0.0 version and the library becomes libunarr.so.1.0.0.

Since the release is tagged, one idea could be to release a 1.0.2 fixing this?

memory leak if 7z is not valid

_7z.c:170
memory allocated by

    _7z->look_stream.buf = ISzAlloc_Alloc(&gSzAlloc, 1 << 18);

but in following error condition line 181 it returned without free it

    if (res != SZ_OK) {
        if (res != SZ_ERROR_NO_ARCHIVE)
            warn("Invalid 7z archive (failed with error %d)", res);
        //----------------> miss   ISzAlloc_Free(&gSzAlloc, _7z->look_stream.buf);  ?
        free(ar);
        return NULL;
    }

leak sanitizer report

=================================================================
==22571==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 262144 byte(s) in 1 object(s) allocated from:
    #0 0x564dd5826879 in malloc (/home/wangxinyu/unarr/fuz/test/fuzzer+0x132879)
    #1 0x7f451a5288a0 in gSzAlloc_Alloc /home/wangxinyu/unarr/fuz/../_7z/_7z.c:8:81
    #2 0x7f451a526855 in ar_open_7z_archive /home/wangxinyu/unarr/fuz/../_7z/_7z.c:170:28
    #3 0x564dd58649c4 in ar_open_any_archive /home/wangxinyu/unarr/fuz/../test/fuzzer.c:5:20
    #4 0x564dd5864b5b in read_test /home/wangxinyu/unarr/fuz/../test/fuzzer.c:20:20
    #5 0x564dd5865021 in LLVMFuzzerTestOneInput /home/wangxinyu/unarr/fuz/../test/fuzzer.c:61:3
    #6 0x564dd572d225 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/ho
me/wangxinyu/unarr/fuz/test/fuzzer+0x39225)
    #7 0x564dd57327d3 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<std::__cxx11::basic
_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx1
1::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/home/wangxinyu/
unarr/fuz/test/fuzzer+0x3e7d3)
    #8 0x564dd5734072 in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::ch
ar_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char,
 std::char_traits<char>, std::allocator<char> > > > const&) (/home/wangxinyu/unarr/fuz/test/fuzzer
+0x40072)
    #9 0x564dd5724d75 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigne
d long)) (/home/wangxinyu/unarr/fuz/test/fuzzer+0x30d75)
    #10 0x564dd5718293 in main (/home/wangxinyu/unarr/fuz/test/fuzzer+0x24293)
    #11 0x7f4519f69222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

Direct leak of 262144 byte(s) in 1 object(s) allocated from:
    #0 0x564dd5826879 in malloc (/home/wangxinyu/unarr/fuz/test/fuzzer+0x132879)
    #1 0x7f451a5288a0 in gSzAlloc_Alloc /home/wangxinyu/unarr/fuz/../_7z/_7z.c:8:81
    #2 0x7f451a526855 in ar_open_7z_archive /home/wangxinyu/unarr/fuz/../_7z/_7z.c:170:28
    #3 0x564dd58649c4 in ar_open_any_archive /home/wangxinyu/unarr/fuz/../test/fuzzer.c:5:20
    #4 0x564dd5864b5b in read_test /home/wangxinyu/unarr/fuz/../test/fuzzer.c:20:20
    #5 0x564dd5865021 in LLVMFuzzerTestOneInput /home/wangxinyu/unarr/fuz/../test/fuzzer.c:61:3
    #6 0x564dd572d225 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/ho
me/wangxinyu/unarr/fuz/test/fuzzer+0x39225)
    #7 0x564dd572fa20 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer:
:InputInfo*, bool*) (/home/wangxinyu/unarr/fuz/test/fuzzer+0x3ba20)
    #8 0x564dd573287f in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<std::__cxx11::basic
_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx1
1::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/home/wangxinyu/
unarr/fuz/test/fuzzer+0x3e87f)
    #9 0x564dd5734072 in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::ch
ar_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char,
 std::char_traits<char>, std::allocator<char> > > > const&) (/home/wangxinyu/unarr/fuz/test/fuzzer
+0x40072)
    #10 0x564dd5724d75 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsign
ed long)) (/home/wangxinyu/unarr/fuz/test/fuzzer+0x30d75)
    #11 0x564dd5718293 in main (/home/wangxinyu/unarr/fuz/test/fuzzer+0x24293)
    #12 0x7f4519f69222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

SUMMARY: AddressSanitizer: 524288 byte(s) leaked in 2 allocation(s).

Path traversal vulnerability

I maintain Golang bindings for unarr at https://github.com/gen2brain/go-unarr and there is this issue reported with tar archives gen2brain/go-unarr#21, along with this CVE GHSA-v9j4-cp63-qv62. Unfortunately, I don't have a sample of such an archive or a method to create such an archive. I see there are such samples at https://github.com/jwilk/traversal-archives but not sure if these can be used to reproduce the issue.

encoding problems in zip files

zip filename encoding can be many variants , which unarr not handled (I tried some zip with unarr, which didn't return correct filename), could unarr add interface to read raw filename instead of trying to decode them ? so client can try harder to guess correct encoding

Cannot unarchive 7z files

Test file:
https://github.com/emukidid/swiss-gc/releases/download/v0.5r922/swiss_r922.7z

Building unarr-test

wget -O unarr-master.zip https://github.com/selmf/unarr/archive/master.zip
unzip unarr-master.zip
pushd unarr-master
mkdir build
pushd build
cmake .. -DBUILD_SHARED_LIBS=OFF -DENABLE_7Z=ON -DBUILD_SAMPLES=ON
make

Running unarr-test

./unarr-test ./swiss_r922.7z

Parsing "swiss_r922.7z":
01. swiss_r922/ActionReplay/SDLOADER.BIN (@11)
! _7z.c:135: Failed to extract file at index 11 (failed with error 4)
Warning: Failed to uncompress... skipping
02. swiss_r922/DOL/Viper/swiss_r922-lz-viper.dol (@12)
! _7z.c:135: Failed to extract file at index 12 (failed with error 3)
Warning: Failed to uncompress... skipping
03. swiss_r922/DOL/swiss_r922-compressed.dol (@13)
! _7z.c:135: Failed to extract file at index 13 (failed with error 3)
Warning: Failed to uncompress... skipping
...

	includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
	libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@