libarchive icon indicating copy to clipboard operation
libarchive copied to clipboard

bsdtar.exe 3.7.0 does not work without libcrypto-1_1-x64.dll

Open hemnstill opened this issue 2 years ago • 11 comments

Windows 10 Home 22H2 19045.3208

Error: The code execution cannot proceed because libcrypto-1_1-x64.dll was not found. Reinstalling the program may fix this problem.

It looks like the behavior changed after this commit: https://github.com/libarchive/libarchive/commit/d3d16ec25d695b186c25f31b6bab1c4401122a3e

SET(CMAKE_REQUIRED_LIBRARIES ${OPENSSL_CRYPTO_LIBRARY})

I want to build static version of bsdtar that working without any additional dll's

hemnstill avatar Jul 19 '23 18:07 hemnstill

I've got the same behavior I've never seen before. Why do we need external cryptographic library in TAR that's not even included in release files?

lelik107 avatar Jul 20 '23 04:07 lelik107

A while ago we've spotted that our use of the wincrypto code is broken.

The mentioned commit fixes a genuine bug and it enforces what was the default for years - use openssl.

Although I can understand the annoyance, that's more of a Windows problem than libarchive's. @mmatuska sounds like we'll need to keep the wincrypt code forever? Unless you're a fan of shipping a release with openssl statically linked in.

The references issues are duplicates. Can anyone @kientzle (?) do the honours and close them ;-)

evelikov avatar Oct 12 '23 13:10 evelikov

Seems the latest release binaries still fail to start;

The dll from python-3.10.11-embed-amd64.zip, once renamed, seems to work -- is this a good choice?

or rather, what is the recommended place to obtain this dll from? How can I know that I am using a compatible version?

9001 avatar Feb 12 '24 09:02 9001

Yes you can use it. The latest Python build with OpenSSL 1.1.1u was: https://www.python.org/ftp/python/3.11.4/python-3.11.4-embed-amd64.zip and they switched to OpenSSL 3 after it.

lelik107 avatar Apr 06 '24 12:04 lelik107

this is really annoying - I will just use another tool I guess

3052 avatar Aug 07 '24 20:08 3052

I think there are three alternatives for us here:

  • Support building without crypto support. This would have to disable all support for encrypted archives, of course, but is similar to what we already do when we cannot locate a functioning LZMA or ZStd library, for instance.
  • Default to using a crypto library that is built into Windows.
  • Build a proper installer for bsdtar that includes redistributable libraries.

If anyone would like to try implementing one of these, please let us know.

kientzle avatar Aug 10 '24 16:08 kientzle

BTW @3052 if you are looking for a very basic tar program with no external dependencies, you might consider this one: https://github.com/libarchive/libarchive/blob/master/contrib/untar.c

kientzle avatar Aug 10 '24 16:08 kientzle

As a 4th alternative, would it be possible to statically link libcrypto into the exe? Or perhaps that is problematic somehow? License-wise it should be alright, and it looks like it should be fine technically as well -- but I have no experience with building for windows, so I could be way off.

9001 avatar Aug 11 '24 09:08 9001

For now bsdtar relies on libcypto-1_1-x64.dll that is not updated publicly anymore, there's no need to recompile it every time. Why not just to build this dll once and place it in a "bin" folder with bsdtar.exe, IDK. The latest public sources: https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_1w

lelik107 avatar Aug 12 '24 04:08 lelik107