Skip to content
This repository has been archived by the owner on Feb 19, 2019. It is now read-only.

improve non-admin and non-elevated installation experiences #583

Open
bbodenmiller opened this issue Oct 4, 2014 · 6 comments
Open

improve non-admin and non-elevated installation experiences #583

bbodenmiller opened this issue Oct 4, 2014 · 6 comments

Comments

@bbodenmiller
Copy link

I think the installation experience could be more straight forward especially for non-admin's who are likely to be less experienced users - they likely are not non-admin's by choice. Continuation/replacement of the discussion at https://github.com/chocolatey/chocolatey.org/issues/96. Perhaps:

  • If the user is an admin in an elevated prompt, simply install to default admin location.
  • If the user is non-admin, warn of consequences and simply install to user location.
  • If the user is an admin but in a non-elevated prompt, ask them to continue install as non-elevated or if they would like to install using elevated prompt (which can be programmatically launched). Go with a default action of continuing after a certain timeout. ( similar to this timeout code, but ensure interactive user )
@dcjulian29
Copy link
Contributor

That has been a sticking point for me as well recently... If you've been around chocolatey for a while, you'll remember that the reason it doesn't install into "Program Files" is because the original thought was to not require "elevated" privileges... recent changes have changed the "default" location to "ProgramData" and added a warning about execution within a "non-elevated" shell. This is all because the developers of the install scripts inside the packages from the public feed don't take adequate precautions to handle the difference between execution in an elevated and non-elevated shell... It is an unfortunate change in direction for the project. I'm hoping that the OneGet project will take a different approach.

@ferventcoder
Copy link
Contributor

That is not the correct reason we chose to move it. It was related to CVEs
that were never made public. It had nothing to do with folks that do not
know how to call the right functions. When stuff fails do to folks not
knowing how to properly call for admin access, the packages should properly
fail.

I'm not really sure how you came to that conclusion as the reason but I've
never stated as much and I've never heard anyone on the team state as much
either.

Regarding the CVE - The old default install location has too many
privileges that allows anyone to make changes to pkg installers or do other
nasty stuff if they get access to a box. There were some other CVEs related
to domain poisoning that we've also fixed.

Further, the old posh version of choco is ending with a new version that is
faster and more stable. Not sure if you have seen that yet. You may want to
sign up for the newsletter if you have not.

Once we get the security stuff ironed out, the plan is to allow easier
non-admin installations again. But it must be done in a way that is secure
for that user and not open to package security issues like before.

On Saturday, October 4, 2014, Julian Easterling [email protected]
wrote:

That has been a sticking point for me as well recently... If you've been
around chocolatey for a while, you'll remember that the reason it doesn't
install into "Program Files" is because the original thought was to not
require "elevated" privileges... recent changes have changed the "default"
location to "ProgramData" and added a warning about execution within a
"non-elevated" shell. This is all because the developers of the install
scripts inside the packages from the public feed don't take adequate
precautions to handle the difference between execution in an elevated and
non-elevated shell... It is an unfortunate change in direction for the
project. I'm hoping that the OneGet project will take a different approach.


Reply to this email directly or view it on GitHub
#583 (comment)
.

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

@dcjulian29
Copy link
Contributor

My intention was never to apply to the fact that I spoke with any authority or that my opinion was correct. I based my opinion solely on the web page at https://github.com/chocolatey/chocolatey/wiki/DefaultChocolateyInstallReasoning. I love the chocolatey project and I use it across a lot of systems to manage applications/settings/customizations. I think the development team of chocolatey have done many great things. I have just found that many (not all) of the package installers on the public feed are crap and don't work consistently on a large number of my systems which contain a lot of variations. Again, not a problem with the chocolatey project itself. But if you're going to constantly display a warning that I'm executing in a non-elevated shell even when I just getting a list of packages (clist), I think that the experience is tainted from the start.

As for stuff failing when not calling the right functions, I've been hit with that several time in the install scripts I written so I'm not immune to the problem either. I've written scripts that run into permission issues, but then chocolatey will still report that the package installed correctly. Chocolatey can only report what the script reports back to it. That is not a fault of Chocolatey project, it is the fault of my script doing a "try/catch" then exiting the script without letting the exception propagate up...

Given that Chocolatey is still not a 1.0 product and that I have not seen the new rewrite yet, and to be honest, I'm still waiting to see what the OneGet project does; however, I will sign up for the newsletter as the chocolatey project has made package management on Windows systems much closer to the same experience I have under the Ubuntu systems I manage. Keep in mind though that any interaction with apt-get requires sudo permissions so I look forward to any tools that allow non-admin installations while still being secure to the system...

@ferventcoder
Copy link
Contributor

But if you're going to constantly display a warning that I'm executing in a non-elevated shell even when I just getting a list of packages (clist), I think that the experience is tainted from the start.

This is partially an artifact of the posh version. Rather than copy and paste that into several locations, I went with keeping it in one spot. It is a bit annoying to see

@ferventcoder
Copy link
Contributor

Given that Chocolatey is still not a 1.0 product and that I have not seen the new rewrite yet, and to be honest, I'm still waiting to see what the OneGet project does; however, I will sign up for the newsletter as the chocolatey project has made package management on Windows systems much closer to the same experience I have under the Ubuntu systems I manage.

OneGet is a package manager aggregator. It will contain Chocolatey, NuGet, PSGet, Python and others.

@ferventcoder
Copy link
Contributor

Also, here's the archive with a link to the video of the new version - http://us8.campaign-archive1.com/?u=86a6d80146a0da7f2223712e4&id=fde33f421e

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants