runtime error: index out of range [0] with length 0

[rgmz]

While processing a large amount of files, I encountered the following panic.

Panic occurred when reading archive     {"error": "runtime error: index out of range [0] with length 0"}

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x21335e2]

goroutine 94212267 [running]:
github.com/bodgit/sevenzip.readHeader({0x3bff3d8, 0xc1c15f9bc0})
        /home/user/go/pkg/mod/github.com/bodgit/[email protected]/types.go:832 +0x2c2
github.com/bodgit/sevenzip.(*Reader).init(0xc1af3e8d80, {0x7f9e8c1b5090?, 0xc1c53ea900}, 0x6d)
        /home/user/go/pkg/mod/github.com/bodgit/[email protected]/reader.go:379 +0x7d3
github.com/bodgit/sevenzip.NewReaderWithPassword({0x7f9e8c1b5090, 0xc1c53ea900}, 0x6d, {0x0, 0x0})
        /home/user/go/pkg/mod/github.com/bodgit/[email protected]/reader.go:242 +0x93
github.com/mholt/archiver/v4.SevenZip.Extract({0x0?, {0x0?, 0x0?}}, {0x3c1a238, 0xc1c53eae10}, {0x3be9340?, 0xc1c53ea900?}, {0x0, 0x0, 0x0}, ...)
        /home/user/go/pkg/mod/github.com/mholt/archiver/[email protected]/7z.go:76 +0x12b
github.com/trufflesecurity/trufflehog/v3/pkg/handlers.(*Archive).openArchive(0xc1c8bc3040, {0x3c1a2e0, 0xc1c433da40}, 0x0, {0x3be9340, 0xc1c53ea900}, 0xc1c15f9b60)
        /home/user/dev/github.com/trufflesecurity/trufflehog/pkg/handlers/archive.go:114 +0x2b3
github.com/trufflesecurity/trufflehog/v3/pkg/handlers.(*Archive).FromFile.func1()
        /home/user/dev/github.com/trufflesecurity/trufflehog/pkg/handlers/archive.go:76 +0x1af
created by github.com/trufflesecurity/trufflehog/v3/pkg/handlers.(*Archive).FromFile in goroutine 59328246
        /home/user/dev/github.com/trufflesecurity/trufflehog/pkg/handlers/archive.go:71 +0xe5

The issue appears to be caused by attempting to access the first (0) value of h.streamsInfo.subStreamsInfo.digest when it is empty. I don't know what the specific culprit was at the moment, but I'm sharing this now in case the issue/solution is obvious.

sevenzip/types.go

Line 825 in 8185d4f

j := 0

sevenzip/types.go

Lines 832 to 833 in 8185d4f

	h.filesInfo.file[i].CRC32 = h.streamsInfo.subStreamsInfo.digest[j]
	_, h.filesInfo.file[i].UncompressedSize = h.streamsInfo.FileFolderAndSize(j)

[bodgit]

If you can provide (a link to) an archive that triggers this bug that would be helpful otherwise I'm a bit restricted.

[rgmz]

Fair enough! I've actually had hard time reproducing this specific issue because I've been hitting another edge case, and that one seems more reliably reproducible. I'll share that today.

[bodgit]

I'm guessing it's something related to the CRC digests being optional, but an example archive would confirm that, and also if it's small enough, it becomes part of the test suite to ensure I don't inadvertently break it again.

[bill-rich]

I'm running into the same issue, but I don't have access to the archive thats causing it. I'll keep working at a repro.

[rgmz]

I've managed to narrow the failure down to a handful of repositories, I just need to figure out the specific repository and file.

Hopefully I'll be able to share a reproducer soon.

[rgmz]

This should work:
https://github.com/slimsag/mega/blob/37ef02d1818ae263956b7c8bc702b85cdbc83d20/chromium/chrome/test/data/safe_browsing/seven_zip/file_and_empty.7z

[bodgit]

This should work: https://github.com/slimsag/mega/blob/37ef02d1818ae263956b7c8bc702b85cdbc83d20/chromium/chrome/test/data/safe_browsing/seven_zip/file_and_empty.7z

Awesome. That's erroring nicely, (in a good way!), and it's small enough I can add it as a new test case. Running 7z l -slt file_and_empty.7z shows there is no CRC data in the archive.

[bodgit]

@rgmz @bill-rich can you try the branch in #143 and see if that fully fixes things? It passes now on the linked archive.

[rgmz]

That seems to work. I'll let you know if I encounter any issues.

Thanks again, @bodgit!