Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Glenn Linderman

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

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com  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.


OK, here is the traceback.  I've upgraded the application from Python 
2.6 + CGIHTTPServer.py + bugfixes to Python 3.2a4 + http.server + 
bugfixes, hoping that it would fix it, but since it didn't that the 
traceback would be more relevant.  It seems that _urandom is the likely 
culprit.


Traceback (most recent call last):
  File d:\my\web\areliabl\0test\https.py, line 5, in module
import server
  File d:\my\web\areliabl\0test\server.py, line 88, in module
import email.message
  File C:\Python32\lib\email\message.py, line 17, in module
from email import utils
  File C:\Python32\lib\email\utils.py, line 27, in module
import random
  File C:\Python32\lib\random.py, line 698, in module
_inst = Random()
  File C:\Python32\lib\random.py, line 90, in __init__
self.seed(x)
  File C:\Python32\lib\random.py, line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Amaury Forgeot d'Arc
Hi,

2010/11/23 Glenn Linderman v+pyt...@g.nevcal.com:
   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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Martin v. Löwis
Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
 Hi,
 
 2010/11/23 Glenn Linderman v+pyt...@g.nevcal.com:
   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-systemroot-in-a-custom-environment-block/

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Glenn Linderman

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 Lindermanv+pyt...@g.nevcal.com:

   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-systemroot-in-a-custom-environment-block/

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).



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Glenn Linderman

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

On Mon, Nov 22, 2010 at 16:54, Glenn Lindermanv+pyt...@g.nevcal.com  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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Martin v. Löwis
 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.

The rationale for moving along with the releases is different, though:
you cannot obtain the old versions anymore, except perhaps on Ebay.
So new developers coming to Python would not be able to build Python
extensions if we didn't always try to use a compiler that is still
available (and we are stressing that a little bit: 3.2 will use
VS 2008, even though it has been already superceded).

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

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-23 Thread Glenn Linderman

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 :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-22 Thread Guido van Rossum
On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman v+pyt...@g.nevcal.com 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.

 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 PYTHONwhatever 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).

 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. :-)

 If anyone knows of documentation listing what environment variables are
 required by Python on Windows, I would appreciate a pointer, searches and
 doc browsing having not turned it up.

 I'll attempt to recreate the test situation later this week with Python
 3.2a4, if no one responds, but the only debug technique I can think of is to
 slowly remove environment variables until I find the minimum set required to
 run http.server successfully for my tests with CGI files.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-22 Thread Glenn Linderman

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

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Lindermanv+pyt...@g.nevcal.com  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 PYTHONwhatever  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!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] is this a bug? no environment variables

2010-11-22 Thread Tim Lesher
On Mon, Nov 22, 2010 at 16:54, Glenn Linderman v+pyt...@g.nevcal.com 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.
-- 
Tim Lesher tles...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] is this a bug? no environment variables

2010-11-21 Thread Glenn Linderman
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).

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 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.


If anyone knows of documentation listing what environment variables are 
required by Python on Windows, I would appreciate a pointer, searches 
and doc browsing having not turned it up.


I'll attempt to recreate the test situation later this week with Python 
3.2a4, if no one responds, but the only debug technique I can think of 
is to slowly remove environment variables until I find the minimum set 
required to run http.server successfully for my tests with CGI files.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com