You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
archive/zip is currently missing support for encrypting and decrypting zip files. This makes it unnecessarily painful to deal with legacy file formats.
This was previously requested as a feature here: #12081, where generally folks were in favor, but no one ever pushed it across the finish line.
There are two common encryption formats that we should support:
ZipCrypto:
This is the original encryption scheme. It has widespread support, so should be added for compatibility purposes. However, it is not secure, so should come with a big disclaimer that new files should only be created for compatibility purposes and the encryption should not be trusted.
WinZip’s AES: This is what WinZip and 7Zip use by default to create encrypted zip files.
For more details on the implementation specifics, please see #12081. @alexmullins talks about his fork of archive/zip that implements WinZip AES. And @yeka has a fork of that which adds support for ZipCrypto.
Adding support for both of these formats into the standard library is relatively straightforward. Unfortunately, as it stands today, it’s impossible to add support for encryption as a wrapper around the standard library archive/zip. A custom compressor/decompressor handler approach doesn’t work because encryption needs at minimum access to the FileHeader. In the case of WinZip AE-2 it even needs to disable the CRC. So libraries have to completely fork archive/zip.
If accepted, I’d be happy to put together the PR implementing this, as I need this for a project I’m working on.
The text was updated successfully, but these errors were encountered:
archive/zip is currently missing support for encrypting and decrypting zip files. This makes it unnecessarily painful to deal with legacy file formats.
This was previously requested as a feature here: #12081, where generally folks were in favor, but no one ever pushed it across the finish line.
There are two common encryption formats that we should support:
ZipCrypto:
This is the original encryption scheme. It has widespread support, so should be added for compatibility purposes. However, it is not secure, so should come with a big disclaimer that new files should only be created for compatibility purposes and the encryption should not be trusted.
WinZip’s AES: This is what WinZip and 7Zip use by default to create encrypted zip files.
For more details on the implementation specifics, please see #12081. @alexmullins talks about his fork of archive/zip that implements WinZip AES. And @yeka has a fork of that which adds support for ZipCrypto.
Adding support for both of these formats into the standard library is relatively straightforward. Unfortunately, as it stands today, it’s impossible to add support for encryption as a wrapper around the standard library archive/zip. A custom compressor/decompressor handler approach doesn’t work because encryption needs at minimum access to the FileHeader. In the case of WinZip AE-2 it even needs to disable the CRC. So libraries have to completely fork archive/zip.
If accepted, I’d be happy to put together the PR implementing this, as I need this for a project I’m working on.
The text was updated successfully, but these errors were encountered: