Alternative to 7zip when installing packages

I just started a job where 7zip is blocked as a potential security threat (I talked to IT about it and unblocking it is basically a nonnegotiable), which basically renders installing most packages impossible.

Is there an alternative to decompress packages without using 7zip, or manually installing packages by decompressing them myself using an authorized software (Peazip)?

Edit: My versioninfo()

Julia Version 1.10.1
Commit 7790d6f064 (2024-02-13 20:41 UTC)
Build Info:
Official release
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 20 × 13th Gen Intel(R) Core(TM) i7-13800H
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, goldmont)
Threads: 1 default, 0 interactive, 1 GC (on 20 virtual cores)     

Any supported way seems unlikely but if Peazip happens to be sufficiently argument compatible with 7zip you can probably get away with monkeypatching

using Pkg
Pkg.PlatformEngines.find7z() = "/path/to/peazip"

Otherwise you can try to point it to a script which rewrites the arguments and then calls Peazip, provided that your security standards allow calling scripts you write yourself.

1 Like

That seems to not be working. I am running Pkg on debug, and I still get that Julia attempts to use 7zip:

Error: IOError: could not spawn setenv(`'path\to\Julia\Julia-1.10.1\libexec\julia\7z.exe' ...)

When you mention script, do you mean a Julia script? A bash script?

Right, Pkg is in the sysimage, it was optimistic to think that would work.

You could try to intercept 'path\to\Julia\Julia-1.10.1\libexec\julia\7z.exe' instead, putting your own script there. But I have no idea how the 7z blocking works.

When you mention script, do you mean a Julia script? A bash script?

Whatever gets the job done.

1 Like

Could you provide the output of versioninfo() or provide information about your oprtating system environment?

I have added my versioninfo() to the original post. I’m basically running Windows 10, so any console commands would use the Powershell scripting.

This is the first time we’ve gotten this issue, so this is very much not configurable. We could make it configurable, but unfortunately that’s not going to help you until Julia 1.12 at this earliest, which won’t be until some time this fall. In the mean time, since Pkg very much hard codes calls to 7z, you’ll have to find the 7z binary in your Julia install and replace it with a little shell script that simulates a limited amount of the command-line behavior of 7z using other tools. That’s not too bad because it’s only called two ways:

  • 7z x $tarball_path -so: extract gzip data from tarball_path to stdout, similar to gzcat
  • 7z a -si -tgzip -mx9 $tarball_path: take uncompressed tarball data on stdin and gzip it to tarball_path

And I’m pretty sure the second way isn’t called in typical Pkg usage. There’s one more usage, but I think it’s only called when precompiling Pkg itself, which probably won’t happen on your local system. Should be fairly easy to cook up a shell script that looks at the way it’s called and emulates those two behaviors using gzip. Why don’t we use gzip? Mostly historical reasons that are no longer relevant. I’ll probably get around to replacing it with gzip soonish.


I had a similar issue, but managed to get IT to allow anything that was installed in the Julia folder and below. (Another 7zip is still blocked, but I clearly don’t need it anymore.)

1 Like

Seems like z7 is particularly problematic and we should put the effort in to get rid of it. Especially now that we really only use it in a way that gzip is a strictly better replacement for. GitHub issue filed: replace 7z with gzip · Issue #3824 · JuliaLang/Pkg.jl · GitHub.


Thank you for the update and raising the issue on Github! So, my understanding from your post is to replace 7z.exe with a shell script named 7z.exe that contains those instructions but using gzip (or tar on Windows) functions?

It needs to be a shell script which, when called like that, invokes gzip to accomplish the appropriate behavior.

Thank you for mentioning peazip. I was not aware of it. It looks really useful!

Would it still need to be called 7zip.exe on Windows though? IT seems to block any instance of 7zip.exe regardless of identity.


That’s very silly. We ship a recent fully patched version of the new p7zip project, that’s not the abandoned and CVE-riddled project by the same name, it doesn’t make sense to block a file just on its name.


That is not entirely correct, for Windows p7zip_jll just contains repackaged 7-zip binaries: Yggdrasil/P/p7zip/build_tarballs.jl at 9631b76a35021f8fff10341fdf942cb7d796e7c8 · JuliaPackaging/Yggdrasil · GitHub
So the blocking might still be hash-based.


Could and should Julia rather use (Windows API, see in EDIT below or) the pure-Julia solution (at least on Windows, and maybe just for Pkg):

I don’t think we should work around insane security policies, but since it’s a known, problem, I at least asking if this would work.

I guess the risk is that Julia itself would start to be blocked by some admins, if it provides a way around 7zip or other similar issues (for those exploiting)…

Windows itself will never be blocked, and it provides an API, should be safe to use…:

Note that recent versions of Windows have tar and curl with gzip support.