webbrowser module + urls ending in .py = a security hole?

[Paul Boddie]

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