Instead of requiring git be installed, use curl/wget to grab the latest release or master.zip?

[espoelstra]

If they can curl https://pyenv.run | bash then we know they can grab files via curl, and on almost all systems (minus Git Bash on Windows), even if they don't have the zip package or the unzip command they likely have python or python3 which includes a ZipFile.extract() function in the standard library. For safety you could try ZipFile.testzip() to see if the zip was corrupted during the download.

[aspiers]

Please don't do this; it is not a good way to install software:

• http://tserong.github.io/sudo-wget/
• https://www.seancassidy.me/dont-pipe-to-your-shell.html
• https://www.reddit.com/r/programming/comments/1pqtcb/curltoshell_russian_roulette/

[robnagler]

@espoelstra Pyenv is a developer tool. If they don't use git, they probably aren't going to need Pyenv to manage multiple Python versions.

@aspiers Here is a counter-argument: https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install

Pyenv is distributed and updated via git, which is curl-bash by another name. The installer could be made more robust, for sure, but pip, npm, brew, etc. could use some work, too.

[aspiers]

@robnagler Thanks for the URL but that is not really a counter-argument, it's effectively an argument for the need for PGP signing, and IMHO a poorly constructed one at that. For example, they say:

Realistically, downloading and installing software while relying on HTTPS for integrity is a widely-used practice. The web sites for Firefox, Rust, Google Chrome, and many others offer an HTTPS download as the primary installation mechanism.

... but conveniently omit that any software distribution sites (including the Linux distros which they are not so subtly attacking here) worth their salt will provide digest hashes and signatures alongside the binary files so that anyone who wants to verify them can. HTTPS is only useful for protecting content in transit, not for proving that it was trustworthy in the first place. They also neglect to mention that when you use a distro's native package installer that it can automatically do GPG verification for you without any extra effort required.

Pyenv is distributed and updated via git, which is curl-bash by another name.

I'm not sure how you can draw equivalence between git and curl|bash. At least git is hash-based and hence has some basic verification built in by design. curl|bash has none.

@tserong, you want to chime in here? Did I miss anything?

[tserong]

@tserong, you want to chime in here? Did I miss anything?

I think you've pretty much covered it :-)

[espoelstra]

I think you guys all missed an important point, the README.md here already tells users to install in this manner.... I'm was just suggesting you could possibly remove the git pre-requirement, I strongly agree with doing the whole pgp/md5/etc validation on files downloaded with curl if you went that route.

https://github.com/pyenv/pyenv-installer#prerequisites

[aspiers]

I think you guys all missed an important point, the README.md here already tells users to install in this manner....

Sorry, you lost me - which manner are you referring to? I don't see anything in the README.md about signatures or any kind of verification.

[robnagler]

@aspiers your assertion that curl|bash has no verification is incorrect. Consider that when you type commands into bash over ssh, every key stroke is verified. That same verification happens when you run curl|bash (over TLS as is the case here). All web transactions rely on this same validation. Your bank's Javascript app doesn't sign the data it transmits to the web server. It relies on the underlying transport, which is more reliable than simple GPG signing, because it is fully encrypted.

Here are the verification steps to ensure the output of curl|bash is correct:

1. The disk has ECC on every block
2. The file system likely has integrity checks
3. The memory likely has ECC
4. The CPU has internal integrity checks
5. The ethernet frames that leave your computer have a 32-bit CRC
6. The IPv4/6 header has a 16-bit checksum
7. TCP ensures the bytes are transmitted in order
8. TLS ensures authenticity of the sender through public key validation
9. TLS further ensures integrity and secrecy of the data
10. HTTP ensures the syntax and header are valid
11. Bash parses the input before executing each command
12. The script will only execute if the entire file is read (discussed below)

You also said that "HTTPS [does not prove the content] was trustworthy in the first place". That is correct, and neither does GPG signing. It could be argued that TLS (not HTTPS) is stronger authentication, because the public key is signed by a certificate authority. GPG public keys are not signed by anybody so anybody can create a key that looks like a distro's key. The key itself is unlikely to be verified by you independently, and even if it was, the signature of that key would come over TLS from a website whose authenticity you would verify only by going to a website whose authenticity you would verify by, you guessed it, TLS. Now maybe you are one of those people who writes a letter or fax to the folks at Fedora to have them send you a key. How do you know that letter or fax wasn't intercepted? You don't. Quis custodiet ipsos custodes?
See Ken Thompson's excellent 1984 Turing Award Lecture on this subject.

As to point (12) above, I will agree that the pyenv-installer should be wrapped in a bash function like the one returned by https://pyenv.run, but that's what I meant when I said it could be more robust.

I do not deny that curl|bash is not package management. But, most package managers are written very poorly and have many flaws that have been exploited by nefarious folks over the years. Containerization has eliminated much of the need for classical package managers for most applications.

However, I digress. The text above explains how curl|bash verifies the integrity of the data and the authenticity of the sender. It is not perfect, but no installer (or software) is perfect.

I'll also add that pyenv is a userland utility. We don't install or run it as root (per the sudo-wget link in your original post). We deploy with Docker images built as an ordinary user so that the vast majority of untrusted software we install (over curl|bash btw) has no access to root either via the installer or installed setuid programs. That's an advantage over classical package managers, most of which default to run as root.

[native-api]

Closing as per

• Instead of requiring git be installed, use curl/wget to grab the latest release or master.zip? #89 (comment),
• Pyenv-Installer also installs the Pyenv-Update plugin which requires the installation to be via Git to be able to update.