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 https://julialang.org/ release
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 20 × 13th Gen Intel(R) Core(TM) i7-13800H
WORD_SIZE: 64
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.
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?
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.)
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?
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)…
EDIT:
Windows itself will never be blocked, and it provides an API, should be safe to use…:
