Mike Miller wrote: > Every change has pluses and minuses. I can't guarantee 100% benefits, only > trying to make the case that the benefits here outweigh them.
If this is your case about the benefits, it's a weak case. Feel free to blog about how to secure a Python installation in multi-user environments, or contribute docs to python.org, or just go ahead and make your own secure installer (seriously - there are enterprises/IT departments that will prefer a "secure by default" version rather than having to secure it themselves). A change that will break many existing users is a huge minus. Even putting this into 3.5 would worry me unless there is a *much* higher-than-usual usage of the prereleases. Here are some more minuses beyond those listed on the issue: * Longer install time (due to having to compile the stdlib to pyc and pyo eagerly) * Larger installed size (same reason) * Incompatibility with existing non-elevating package installers (every bdist_wininst is in this category, I believe) * Incompatibility with tools that don't recognize user site-packages Incidentally, forcing normal users to elevate to install packages is a bigger security risk than we currently have, since installers (or setup.py's) do not run elevated. Once everyone "knows" that you need to elevate for this (and trust me, people already expect it), *any* package could become the delivery mechanism for malicious code that will be run with admin privileges - no exploits, just social engineering. Right now, we are actually more secure for the vast majority of single-user environments, since people aren't expecting a UAC prompt and will view it with suspicion. > Since we are talking about humans, I'd gather most of them trying to install > something on Windows will have heard about ProgramFiles and not be too > bothered > at its inclusion in the path. Modifying PATH is not recommended by Microsoft (App Paths are - http://msdn.microsoft.com/en-US/ee872121.aspx), and your entire argument in support of using Program Files is that it is Microsoft's recommendation. It's only a minor inconsistency, but be aware that you are weakening your own argument here :) "Heard about ProgramFiles" and "inclusion in the path" are two very different ideas. My grandmother knows about Program Files (though the "x86" still confuses her), but doesn't know anything about PATH. If someone installed Python for her and her "trick" of typing "news.txt" into the Run dialog* suddenly broke, I'm sure she would be unhappy. (*She has no such trick, to my knowledge, but this is one of the side-effects of modifying PATH.) Or if someone dropped a "sol.py" ahead of sol.exe (the user profile directory will work, provided the file is not in App Paths) and the PATHEXT change caused the Python file to be run instead of the EXE. The unintended consequences are significant, which is why I argue that python.org Python should not be installed on my grandmother's computer - there is a difference between the Python development environment and the runtime environment. My basic argument is not that you are wrong, but that it is too late to change. If we were starting from scratch right now, the reference installers from python.org would absolutely install Python into Program Files. But it is far too late to change it for 2.7.x, and it would require a serious education campaign for 3.5 to make sure as many users as possible are not burned. Now is the time to start publicly making a noise about the risks of the current installer and how to mitigate them (the second part is important - otherwise you are just making noise). Cheers, Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
