Peter Hansen wrote: > > I'd agree. I suspect this ought to be reported as a security flaw, > though it would be nice to know what the fix should be before doing so. > Anyone know a more suitable approach on Windows than just passing > things off to startfile()?
I wouldn't mind knowing if os.startfile is the best way to open resources on Windows, and whether there's a meaningful distinction between opening and editing resources that is exposed through an existing Python library. My interest is in making the desktop module a useful successor to webbrowser: http://www.python.org/pypi/desktop Of course, since desktop.open leaves the exact meaning of "to open" to the user's desktop configuration, if that configuration then causes a Python program to be executed without some kind of confirmation, there's a fairly good argument for claiming that the configuration is broken - yes, it's the classic Microsoft convenience vs. security dilemma, circa 1998. For webbrowser, the opportunity to move blame to the user's environment is somewhat reduced, since the expectation of "browsing" a Python program would often be to show the text of that program. Given that webbrowser, in order to do its work, may rely on some environment mechanism that doesn't have the same view of "browsing" programs, there is a good argument for decoupling the module from those mechanisms entirely, although I can imagine that the resulting code would struggle even then to do the right thing. Paul -- http://mail.python.org/mailman/listinfo/python-list
