smihica / pyminizip

To create a password encrypted zip file in python.
Other
108 stars 38 forks source link

pyminizip.compress_multiple password won't work #25

Open Meow-ops opened 6 years ago

Meow-ops commented 6 years ago

When using pyminizip.compress_multiple, the input password does not work.

veon82 commented 6 years ago

pyminizip.compress_multiple(['file1','file2'], [], 'output.zip', 'password', 5) works fine for me

bk-equityzen commented 6 years ago

I'm also having this issue starting from 0.2.3. It works in my shell, but i think when used by django it doesn't work?

Python v 2.7.15

veon82 commented 5 years ago

I'm also having this issue starting from 0.2.3. It works in my shell, but i think when used by django it doesn't work?

Python v 2.7.15

I also noticed some strange behaviors introduced from version 0.2.3. The only change from version 0.2.2 was the build process (embedded zlib was actually used). In PR #26 I tried to fix the build removing duplicated files from src folder and I upgraded embedded zlib to version 1.2.11.

Can you try to build the module from my branch and test if it solves your issues in django?

wolfly22 commented 4 years ago

python:3.8.1 pyminizip:0.2.4

DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

Ailibert commented 3 years ago

I also encountered the situation that the password does not work. Is there a good solution now?

nebbish commented 1 year ago

I just found this github issue -- after first experiencing the problem and investigating locally for a while first.

I am using this library in my work environment, where I need the password feature to work on Windows, Linux, and Mac. It turns out for me, using version 0.2.6, that the password feature works fine on WIndows & Linux -- only Mac is broken. (tried with MacOS 13.4.1 and 12.4)


I even tried to ensure the "text" going through the Py-code was correctly getting passed into the zlib API, so I forked this repo, and added a trace statement in _compress of the final char* value before calling zipOpenNewFileInZip3_64 -- and it printed the password as I passed it in. 😕

So then I cloned my fork onto a MacOS Ventura 13.4.1 with the built-in Python 3.8 -- which has no xcode bits other than whatever comes default with the OS. The wheel built fine, and installed fine. The trace showed the password fine --- but it still did not work! 😣


I see that this repository includes a copy of zlib 1.2.11 (i think just for the headers -- I'm kinda new to building wheels) I wanted to check my MacOS to see which zlib actually got used at run-time -- but I'm also new to MacOS, not sure where to find the files. I am now running system wide finds to locate the headers & libraries that are already on my system so I can compile directly from my system. (still in progress)

So while I'm stuck waiting, I can at least I can share the small stand-alone PY script I've been using to validate the password feature:

import os, click, tempfile, pyminizip, zipfile

PWD = "wXGTZJ9L5C"  # from some pwd-generating web-site, just fodder for repro
data_files = { "one.txt" : b"hello world!\n", "two.txt" : b"booya kada\n" }

@click.command
@click.argument('password', default=PWD)
def cli(password):
    with tempfile.TemporaryDirectory() as tmp:
        paths = []
        for (name,data) in data_files.items():
            paths.append(os.path.join(tmp, name))
            with open(paths[-1], 'wb') as f:
                f.write(data)

        dat = os.path.join(tmp, "test.zip")
        pyminizip.compress_multiple(paths, [], dat, password, 9)

        with zipfile.ZipFile(dat, 'r') as zf:
            for (name, data) in data_files.items():
                dat_content = zf.read(name, password.encode())
                assert dat_content == data, f"{name}'s content from the zip did not match orig, zip content: {dat_content}"

if __name__ == '__main__':
    cli()

If this runs fine -- the password worked, and was successfully used to decompress/decrypt using the built-in library.

NOTE: the password needs to be bytes for the zipfile module, but for this (pyminizip) I believe the Py-C code (with the "Z#" format) can accept either bytes or str and will auto-encode str using UTF-8. This seems to work just fine, since my fork's trace statement shows the right password string was parsed and passed around correctly by the C-code.