Do not print PowerShell install/update scripts by default

[christianrondeau]

When running chocolatey without the -y flag, the script that will be run is printed by default. I suggest not doing that.

I believe that most users will skip them or trust them, regardless of whether they are printed or not. Also, it creates a very long output that is harder to read. Finally, the user is still running a script that is intended to run another executable and modify the system.

Here are some options I believe would allow more advanced users to still take advantage of this feature:

• When asking whether the user wants to run the script or not, add an option to print it (e.g. Yes/No/Skip/Print)
• Add a global setting to enable script printing

For more information: https://groups.google.com/forum/#!topic/chocolatey/UVncL7PxXRg

(Moved from chocolatey-archive/chocolatey#690)

Note: Similar to #178 but rather than suggesting confirmation is not needed, I'm here suggesting that we don't print by default; #53 (Yes to all) and the global settings are sufficient IMHO.

[ferventcoder]

We'll want to split the non-moderated piece, it will be until we have package signing before we can add that.

[christianrondeau]

Removed the part that said "Flag non-moderated scripts (a warning saying the user should print)"

[christianrondeau]

I have a first implementation ready to go. Here's what the output looks like:

kitty.portable v0.63.2.2
The package kitty.portable wants to run 'chocolateyInstall.ps1'.
Note: If you don't run this script, the installation will fail.
Do you want to run the script?
 1) yes
 2) no [Default - Press Enter]
 3) print
3
------ BEGIN SCRIPT ------

# note: we cannot find public url to download from, so download them from http://www.9bis.net/kitty/?page=Download and put them in tools
#$scriptPath = $(Split-Path -parent $MyInvocation.MyCommand.Definition)
#$fileFullPath = Join-Path $scriptPath 'kitty.exe'
#Get-ChocolateyWebFile 'kitty' "$fileFullPath" 'http://www.fosshub.com/download/kitty.exe'

# note: already called by default
#$installDir = $(Split-Path -parent $MyInvocation.MyCommand.Definition)
#Get-ChocolateyBins $installDir


------- END SCRIPT -------
Do you want to run this script?
 1) yes
 2) no [Default - Press Enter]

Here's what's new:

• Replaces "skip" by "print" (covers Remove the warning note about skipping, and instead show the warning when selecting skip #183)
• When "print" is selected, the script is printed
  • The script is in white, surrounded by green fences
• After the print has been printed, the question is asked again, but this time without the option to print, and replaced "the" by "this" (since it is now known by the user)

If everything is good, I will issue the PR (click here to see the code changes). You'll notice that again there is no new tests, since it only changes the output and console prompt, and I could not find tests that verified that (related to that discussion... since most of my PRs for now are related to console output, I only verify that all tests are green and test manually in a console)

[ferventcoder]

Like it.

[ferventcoder]

Merged into stable at ccd3c65 and will be released in 0.9.9.5

[ivanatpr]

This change seems misguided to me, reducing the script confirmations to something just shy of security theater. With this change, the interface now suggests that the normal behavior is to make a decision without looking at the script, which makes the default behavior of asking for those confirmations in the first place seem silly. You're preserving almost all the pain of the confirmations (which is flow-stopping prompt itself, not the messy output) while greatly reducing their main benefit (letting people know exactly what's being run and, more importantly, putting as many eyeballs as possible on each install script making it far more likely that the community will catch any malicious or buggy scripts that slip through moderation).

To put it another way, in my mind, this is what the new flow basically amounts to:

User: Install this app
Choco: In order to install something I gotta run an installation script. Crazy, right? Should I go ahead and do exactly what you just told me to do?

Meanwhile, the old way at least made a bit of sense:

User: Install this app
Choco: In order to install that app I gotta run the following script:
<script contents printed here.>
<Observant technical users can plainly see that chocolatey isn't just running the app's installer directly or some tightly constrained DSL but rather that they've actually just downloaded a random script that they're about to run in an elevated shell. Paranoia Intensifies.>

[ferventcoder]

@ivanatpr I agree and disagree. Right now some of these are a wall of text (which makes some folks eyes gloss over). What I think we will move towards is an even better way to inspect package contents (as in open package folder and let me see it), so that a user can make a decision on whether they want to run the scripts or not.

[christianrondeau]

@ivanatpr My thoughts, since I participated to this:

• Even though we print the PowerShell script, we cannot verify that the installer executable/msi is safe, or that the script doesn't run another malicious script
• Not everyone can understand PowerShell at all, so the feature will be seen as "noise" for some
• Some scripts are quite long, and without color coding, it's hard to see malicious code (especially if someone wants to hide something, or when running cup all)
• Running choco with the -y flag or running them in an automated script (widely used, e.g. boxstarter) will hide the scripts anyway
• Anyone who cares about what runs on their machine can still easily choose to print scripts one at a time
• There is a moderation process being put in place, which should increase the trust in chocolatey packages (at least as much as the installer itself)
• No other package manager (at least that I know about) does that, including apt-get or even npm (even though that last one does not run with administrative privileges)

I personally think your point is still valid, and I do like @ferventcoder's idea of allowing the user to open and inspect the install script, the installer file and anything else it downloads on your machine. There could be other improvements, but I guess the whole point of chocolatey is to make it easy and straightforward to install software on your machine...

I'd be curious to know how other package managers deal with that issue.