Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mz_crypt.h is missing macros like zencode and zdecode which is breaking the compatibility #806

Open
ljavorsk opened this issue Oct 30, 2024 · 4 comments
Labels
compatibility Backwards compatibility

Comments

@ljavorsk
Copy link

ljavorsk commented Oct 30, 2024

The crypt.h in the madler/zlib contains macros zencode [1] and zdecode [2] used by some external applications, but these functions are missing in the minizip-ng, thus breaking compatibility.

I've tried to find where they disappeared, and it looks like commit 4138ca5 has removed the whole crypt.h and crypt.c files, then it was replaced by mz_stream_pkcrypt_decode in commit d7814e9, but after that, there must have been some force-push, and the history of removing this function is gone.

[1] https://github.com/madler/zlib/blob/d476828316d05d54c6fd6a068b121b30c147b5cd/contrib/minizip/crypt.h#L77
[2] https://github.com/madler/zlib/blob/d476828316d05d54c6fd6a068b121b30c147b5cd/contrib/minizip/crypt.h#L74

@nmoinvaz
Copy link
Member

nmoinvaz commented Oct 30, 2024

  • Is there a redhat issue/bug open for this?
  • What project is this affecting?
  • What is the use case for using those two #defines?
  • zencode and zdecode are used by static/internal functions, I'm not certain this is expected to be part of the public API.

I am open to pull requests if there is a way it can be shimmed by calling mz_stream_pkcrypt_decode, but my guess is they are using more than just zencode and zdecode from crypt.h.

@nmoinvaz nmoinvaz added the compatibility Backwards compatibility label Oct 30, 2024
@yarda
Copy link

yarda commented Oct 30, 2024

I hit it when I was trying to compile tcl-9.0.0 with the system zlib, which is now zlib-ng on fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=2318255

Unfortunately, I also wasn't able to compile it with the system zlib-1.2.13-4.fc39. The package bundled zlib-1.3.1 and I don't know whether it would compile with system zlib-1.3.1 (because we don't have it in Fedora) or whether it's just exploiting some internal non public API.

@nmoinvaz
Copy link
Member

It appears that TCL has its own internal zip manipulation library and only uses crypt.h for encrypting part.

@nmoinvaz
Copy link
Member

I have added a crypt.h to the compat folder. It probably needs testing with distributions to make sure the includes are in the right places.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Backwards compatibility
Projects
None yet
Development

No branches or pull requests

3 participants