The lib should under no circumstances panic due to invalid input files. I ran into a case where this happened during fuzzing. And identified a few others.
Expected Behavior
Never panic due to input file.
Actual Behavior
$ grep panic -r unipdf
unipdf/core/security/crypt/filter_aesv2.go: panic(err)
unipdf/core/security/crypt/filter_aesv3.go: panic(err)
unipdf/core/security/crypt/filter_v2.go: panic(err)
unipdf/core/security/ecb.go: panic("crypto/cipher: input not full blocks")
unipdf/core/security/ecb.go: panic("crypto/cipher: output smaller than input")
unipdf/core/security/ecb.go: panic("crypto/cipher: input not full blocks")
unipdf/core/security/ecb.go: panic("crypto/cipher: output smaller than input")
unipdf/core/security/standard_r6.go: panic(err)
unipdf/core/security/standard_r6.go: panic("wrong size")
unipdf/internal/textencoding/differences.go: panic("differences should not be nil")
unipdf/render/internal/context/imagerender/path.go: panic("bad path")
All of those look like they could cause panic because of invalid PDF input files, which is not acceptable.
If the functions have a finalized API need to log a debug Error message and ignore the error or use a handler with default values (if applicable). Expect to cause an error down the line.
Description
The lib should under no circumstances panic due to invalid input files. I ran into a case where this happened during fuzzing. And identified a few others.
Expected Behavior
Never panic due to input file.
Actual Behavior
All of those look like they could cause panic because of invalid PDF input files, which is not acceptable.
If the functions have a finalized API need to log a debug Error message and ignore the error or use a handler with default values (if applicable). Expect to cause an error down the line.
Attachments
N/A