Init simple installer

[bohendo]

resolves #811

This script will:

• exit if echidna is already installed
• exit if python3 is not installed
• install pip3 if not already present
• install slither via pip3 if not already present
• download the mac or linux tarball per current system
• verify checksum
• unpack & place echidna executable at $HOME/.echidna/bin/echidna
• add PATH update to .bashrc or .zshenv or other shell-specific config

This has been tested manually on MacOS.

TODO:

• upgrade old echidna to latest version (basic layout of $HOME/.echidna is well suited to supporting this feature)
• add automated tests for MacOS + Linux
• add Windows support + tests
• optional: host this script somewhere memorable & easy to type out on the command line

[elopez]

Great work @bohendo! 🎉 I left some thoughts inline

[elopez]

It would be cool to have slither updated if it's out of date. PATH may also need to be adjusted to account for slither installed with --user.

Maybe we should use a (fresh?) venv instead and just link slither{,-*} and crytic-compile to the directory we then add to the PATH for echidna?

[elopez]

we should differentiate ARM vs x86 builds, maybe by inspecting uname -m. Otherwise M1 users will get slow fuzzing performance.

[bohendo]

Is there a separate release for ARM vs x86 macs? Under release assets I only see MacOS vs Ubuntu vs Windows

[elopez]

@bohendo yeah, there's MacOS-aarch64 files, with a different structure inside the tarball, e.g see https://github.com/crytic/echidna/releases/tag/v2.1.0

These are manually built (with the nix bundle target in the readme), compressed and uploaded; it seems the latest release is missing them. We used to have a more comprehensive build process that generated a ready to upload archive and fixed TERMINFO on the resulting binaries (the current process has this bug again), maybe we can bring that back to aid releases going forward?

[elopez]

Our digests are not signed, so someone tampering with the releases may also modify the digest. Is this meant only as an integrity check? Otherwise hardcoding the hashes next to the version in the script may provide a bit more of certainty (unless someone tampers with the script as well)

[bohendo]

Just integrity, hardcoding the hashes seems like a better path forward 👍

[gustavo-grieco]

I think we should address @elopez concerns and then merge.

[0xalpharush]

Suggested change

	slither_version="0.9.3"
	slither_version="0.9.6"

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

bohendo seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}