On 11/22/2010 8:33 AM, Guido van Rossum wrote:

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman wrote:

...

In reviewing my notes from my experimentations with CGIHTTPServer (Python2.6) and then http.server (Python 3.2a4), I note one behavior I haven't reported as a bug, nor do I know where to start to figure it out, other than experimentally.

The experiment: launching CGIHTTPServer without environment variables, by the simple expedient of using a batch file to unset all the existing environment variables, and then launching Python2.6 with CGIHTTPServer.

So it failed early: random.py fails at line 110 (Python 2.6). What specific traceback do you get? In my copy of the code that line says

a = long(_hexlify(_urandom(16)), 16)

and I could just imagine that _urandom() fails for some reason to do with the environment (it is a reference to os.urandom()), which, being part of the C library code, might depend on the environment.

But you're not giving enough info to debug this.

Yep, that's the line. I'll have to re-run the scenario, but will do it on 3.2a4, hopefully tonight or tomorrow, to get the traceback.

...

I suppose it is possible that some environment variables are used by Python directly (but I can't seem to find a documented list of them) although I would expect that usage to be optional, with fall-back defaults when they don't exist. That is certainly the idea, but the fallbacks may not always be nice.

Environment variables used by Python or the stdlib itself are supposed to be named PYTHON<whatever> if they are Python-specific, and there's a way to disable all of these (-E). But there are other environment variables (HOME and PATH come to mind) that have a broader definition and that are used in some part of the stdlib. Plus, as I mentioned, who knows what the non-Python C library uses (well, somebody probably knows, but I don't know of a central source that we can actually trust across the many platforms where Python runs).

OK, thanks for the philosophy statement. That's what I didn't know, being new.

...

I suppose it is even possible that some Windows APIs might depend on some environment variables, but I expected that the registry had replaced such usage completely, by now, with the environment variables mostly being a convenience tool for batch files, or for optional, temporary alteration of particular settings. That sounds like wishful thinking. :-)

Well, wishful thinking from me regarding the Windows and the registry is that Windows would be better off without a registry. But it seemed like their direction was instead to do away with environment variables, but in any case, I have little idea if they've achieved it, but should have achieved something in 6.1 versions of Windows!

On 11/22/2010 2:56 PM, Tim Lesher wrote:

On Mon, Nov 22, 2010 at 16:54, Glenn Linderman wrote:

...

I suppose it is possible that some environment variables are used by Python directly (but I can't seem to find a documented list of them) although I would expect that usage to be optional, with fall-back defaults when they don't exist. I can verify that that's the case: Python (at least through 3.1.2) runs fine on Windows platforms when environment variables are completely unavailable. I know that from running our port for Windows CE (which has no environment variables at all), cross-compiled for Windows XP.

Is the Windows CE port generally available? From where? The CE ports I have found in past searches seem to have been quite outdated and not much on-going activity.

Hi, 2010/11/23 Glenn Linderman :

  File "C:\Python32\lib\random.py", line 108, in seed     a = int.from_bytes(_urandom(32), 'big') WindowsError: [Error -2146893818] Invalid Signature

In the subprocess documentation http://docs.python.org/library/subprocess.html """On Windows, in order to run a side-by-side assembly the specified env *must* include a valid SystemRoot.""" Can you keep this variable and start again? -- Amaury Forgeot d'Arc

On 11/23/2010 3:55 AM, "Martin v. Löwis" wrote:

Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:

...

Hi,

2010/11/23 Glenn Linderman:

...

File "C:\Python32\lib\random.py", line 108, in seed a = int.from_bytes(_urandom(32), 'big') WindowsError: [Error -2146893818] Invalid Signature In the subprocess documentation http://docs.python.org/library/subprocess.html """On Windows, in order to run a side-by-side assembly the specified env *must* include a valid SystemRoot.""" Indeed, setting SystemRoot might solve this problem. According to

http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-sy...

CrypoAPI, in Windows 7, requires this variable be set. Failure to find the enhanced crypto provider would explain why the "random" module of Python fails to work.

The specific cause is in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft Strong Cryptographic Provider has as it's ImagePath value

%SystemRoot%\system32\rsaenh.dll

So the registry (and COM) do rely on environment variables.

Regards, Martin

I find it sad but hilarious that after working so hard to remove the need for environment variables from Windows that M$ has introduced new dependencies on them. I wonder if this particular registry variable is simply an oversight/bug on M$' part, that they will eventually fix, or if it a turnaround toward the use of more environment variables in the future. Hmm. Time will tell, I suppose. I'm unaware of any benefits in _changing_ SystemRoot to other values, so not pre-expanding it in that registry location seems only to add an unnecessary dependency on the environment. Indeed, preserving that one environment variable allows my version of http.server to proceed with, as far as initial testing can determine, proper behavior. Thanks for your help in figuring this out. That was a lot faster than a "binary search" to choose which variable(s) to preserve. My purpose in such testing was two-fold: firstly, web servers, for security purposes, generally limit the number of environment variables that are seen by CGI programs, and secondly, in debugging whether or not http.server was properly setting the necessary environment variables, the many other environment variables were cluttering up log dumps of all environment variables. It will be nicer to limit the "passed through" environment variables to SystemRoot, as see how things go. I have read some about side-by-side assemblies but had considered them a good reason to stick with the outdated M$VC 6.0 compiler, which doesn't seem to need to create them, and their myriad requirements, which seem far from necessary for simply compiling a program. I was disappointed to realize that Python was heading down the path of using the newer tools that create side-by-side assemblies, but I suppose using an old and crufty compiler like M$VC 6.0 cannot support some of the newer features of Windows, which may seem to be necessary to some.... like 64-bit support, which does seem necessary, even to me. I was well aware that shortcuts and the registry _may_ refer to environment variables, and have a number of environment variables of my own which leverage that capability, to avoid hard-coded drive letters and paths in certain areas, and for the convenience of shorting the specification of some of the long-winded path names that Windows foists upon us (some of those have been significantly shortened in Windows 6.1, and maybe 6.0 which I used only for 2 months with disgust; 6.1 has helped alleviate the disgust, but I still recommend XP for people that don't need 64-bit capabilities).

On 11/23/2010 12:33 PM, "Martin v. Löwis" wrote:

In any case, VS 2010 will stop using SxS for the CRT.

Good news! Maybe M$VC will become a useful compiler yet again :)