do not download dependency during installation

[blshkv]

We have discovered that the tool downloads its dependencies during installation. This is a typical behavior of malicious software and is getting blocked in a sandbox environment such as Gentoo portage.
So we have to remove the tool (pentoo/pentoo-overlay@f40dd2a).

Please add requirements.txt file with all dependencies and verify them before installing it on your own.

[blshkv]

ok, it is complicated. The issue is with .so shared library which is provided within each binary and it is different for each platform. I would be happy to compile frida-core or whatever required package but it is fails with latest capstone (and may be other libs). I'm basically hitting the old bug frida/frida#130 or capstone-engine/capstone#757

[oleavr]

We do this to work around PIP's lack of support for prebuilt binaries. The .egg format supports this, so our setup.py downloads the .egg and extracts the prebuilt binding pretending it just built it. It's a pretty nasty hack.

I would however not recommend building Frida without Frida's forks of the upstream dependencies, especially GLib which we've patched to support dynamic unloading, fork()-handling, and more. We have also patched libffi with custom API to be able to keep track of the pages it allocates, so we can hide them from Process.enumerateRanges() and similar APIs. This is important for Frida-based memory dumping tools, that don't want to deal with "noise" from Frida's own allocations.

[oleavr]

By the way, there's a fallback where we look in the home-directory for the prebuilt .egg if the download fails. It's not great, but perhaps we could come up with a better workaround until somebody volunteers to do proper packaging.

[blshkv]

ok noted on the customisation part. That make sense, will not try to use system tools anymore.

Regarding prebuilt binaries, I can suggest to create frida-bindings package which would only distribute python code and call a system .so library installed by a relevant package (frida-core?). For example, radare2-bindings or nfqueue-bindings are designed in this way and it worked well for everybody.

The fallback is exactly the way how I patched it now. But I had to remove network part so that it won't try to connect and not to raise a warning since there is no offline option

[mhsmith]

I see you decided in #38 not to use wheels because PyPI didn't support Linux wheels at the time. That restriction has now been lifted (https://github.com/pypa/manylinux/), so you might want to revisit the idea.