Cœur
Cœur
confirmed on current main branch Some notes here: > uncompressed_size = 4 > aes_version = 0 > pk_verify = 19074 So it's only 4 bytes of data (which content is...
The "guilty" code could be: https://github.com/ZipArchive/ZipArchive/blob/be6ac340cbe394cc6a81eae6034a91a7702d9db3/SSZipArchive/minizip/mz_strm_pkcrypt.c#L166 Because it will skip the check when verify2 is 0, which happens to be the case with "1989" on that specific content "test".
That line of code still exists in latest minizip: https://github.com/zlib-ng/minizip-ng/blob/fe5fedc365f7824ada0cf9a84fb79b30d5fc97a8/mz_strm_pkcrypt.c#L166 And it was like that since year 2017: https://github.com/zlib-ng/minizip-ng/commit/18a30653b1eb5e9f96ebc5ec1d93313d229bc731 You'll want to post your issue to https://github.com/zlib-ng/minizip-ng/issues and ping @nmoinvaz.
I also found this on internet: https://stackoverflow.com/questions/53552562/why-the-zip-appnote-on-pkware-website-didnt-mentioned-the-correct-password-chec There seems to be an undocumented way for checking passwords.
> You'll want to post your issue to https://github.com/zlib-ng/minizip-ng/issues and ping @nmoinvaz. I'll track it here: https://github.com/zlib-ng/minizip-ng/issues/800
Nathan just fixed the bug, so I'll soon update minizip to get the fix in ZipArchive.
Pinging the relevant persons: - @sweetppro has been maintaining the autoresize feature on macOS. - The last changes on autoresize were done by #6321 by @Artoria2e5 and reviewed by @nevack...
Related PR: #1690 In my PR, I quoted the specs, and addressed the most dangerous cases for field-names (but not for field-values).
Those interested in the feature should open their own PR. I wrote regarding adding a test for this feature: >do not plan to write one myself I'm glad @zuiwuchang and...