On Sat, Jul 26, 2003, Alex Martelli wrote:

On Saturday 26 July 2003 18:45, Aahz wrote:

...

Given that the IDLE bug doesn't affect Apple (they don't ship Python with Tkinter), I suggest that we not run around like chickens to fix the IDLE bug, but plan on a 2.3.1 release by end of August.

What I'd recommend doing for now is putting a big note on the 2.3 download page (not on the front page as Anna suggests).

Maybe a reasonable compromise -- download page, "what's new", and assorted README files. Updating those won't break anything. after all.

Fine by me.

Still, passing errors off silently when they've not been explicitly silenced IS a bug, as well as a violation of the Python Zen -- and that seems to be what IDLE is currently doing. Documenting the bug is better than nothing, but putting out a 2.3 release with such a known bug "because that bug won't affect Apple" (with its whopping, what, 5% of the market vs Microsoft's 90%+...?) still leaves me a bit perplexed. Decision up to the release managers, of course, but as for me personally I'd like 2.3 to have a bit more than just these updates to python.org & informal docfiles to make the user aware that [a] socket bugs may be impeding his use of IDLE AND [b] IDLE is NOT trying to send information out surreptitiously. Not fixing bugs (that might be too hard to do right now for 2.3 and missing 2.3's deadline is just not an option) but making sure "cards are on the table"...

My point is that by putting a note on the download page, it's likely that few people will upgrade until 2.3.1 comes out, particularly if they know they only need to wait a month. It's doubtful that any embedded systems other than Apple will use 2.3. Alex, you've got commit privs and you're a decent writer ;-), so why don't you go ahead and make the changes to the README and What's New files (other than IDLE's README, which Kurt will handle). If Barry doesn't like the changes, he can revert them. Barry or I will handle the download page. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz

Skip Montanaro writes:

I see nothing wrong with letting this IDLE problem slip through to the 2.3 release with notes in the relevant readme-type documentation. It's simply been discovered too late to fix in this release given that we are at 2.3c2.

In the interest of at least partially resolving these issues for 2.3 without major code changes: [KBK]

Two separate issues:

1. Failure of IDLE to initialize its subprocess doesn't result in a message visible to the user.

A message can be displayed to the user if we configure the Windows installer to bind the IDLE icon to python.exe instead of pythonw.exe. That way a DOS box will open behind IDLE and any messages will be visible there. This is a small patch. [KBK]

2. Unnecessary user aggravation (I'm paranoid, too) caused by personal firewall software complaining about use of the loopback interface.

A very restricted change to the code would be add the following to the banner printed at the top of the shell when it starts (the socket connection isn't made until the shell window opens): *************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. *************************************************************** This involves an addition to PyShell.py:PyShell.begin(), line 873. In addition, the .../idlelib/README.txt would be updated with the same message w/o the asterisks. These are not the final solutions. A pop-up for #1, everytime, and a pop-up for #2 on first use would be introduced into 2.3.1. The above banner could be retained even after the popup is implemented, though I'm -1 on that. Comments? -- KBK

Alex Martelli writes:

"release candidates" are supposed to help us find critical bugs AND FIX THEM before final release. I opine these bugs that we've found ARE critical enough, to enough Python would-be-users on the numerically dominating platform (WIndows), that we should do some minimal effort to fix or at least clearly indicate them (given that one is a missing diagnosis of a user-machine configuration bug, and the other a perfectly acceptable behavior that some buggy but popular pieces of software misdiagnose as IDLE trying to connect to the internet...) in places where users will SEE the indication (download page is good but not quite sufficent IMHO).

Um. While I understand the issue involved, I find it hard to be quite as convinced as this, that the issue is a bug. First of all, I would say that on a correctly functioning machine, applications should be able to listen on, and send to, unprivileged (> 1024) ports on the local machine (127.0.0.1). In that case, I don't see a bug in Python, or in IDLE. There may be "bugs" in certain systems, whereby such ports are not available, but that isn't Python's fault. In thinking about this, however, there *is* one major point which I think needs to be considered. As I understand the issue, IDLE runs as 2 processes which talk via a socket. I assume that it is not possible for this socket to be used by anything *other* than IDLE - in particular, random hackers can't use the open socket as a means of exploit? Such a security hole would, indeed, be a major bug which needs to be addressed. Assuming no such security hole, what remains is an education issue. This is exacerbated by the tendency of some "personal firewall" products to ask the user for his/her opinion on all sorts of otherwise innocent network traffic - often the user has no way of giving an informed opinion, and the question does nothing but foster paranoia. Sure, the fact that people might ask "why is Python talking to the internet?" is worrying. But surely the correct answer is to say firmly, but in the politest possible way, "it's not - whatever gave you the impression that it is, is mistaken". Explanatory dialogs might help for some people, but you risk hitting the other problem, of annoying people who *do* understand what's going on by looking patronising. Paul. -- This signature intentionally left blank

"Tim Peters" writes:

...

In thinking about this, however, there *is* one major point which I think needs to be considered. As I understand the issue, IDLE runs as 2 processes which talk via a socket. I assume that it is not possible for this socket to be used by anything *other* than IDLE - in particular, random hackers can't use the open socket as a means of exploit? Such a security hole would, indeed, be a major bug which needs to be addressed.

I don't know the answer, and agree it should be taken seriously. For example, a port that accepts arbitrary Python code and executes it is as dangerous as anything I can imagine. But I haven't studied the new IDLE code, and don't know what the risks are.

An open execution server on an external interface is exploitable at the privilege level of the user which initiated it. At GvR request, the connection was reversed so that the execution server connects to the user's GUI process. If the local cracker manages to intercept the loopback interface (no external packets) he can then access IDLE's stdout and stderr streams in the user GUI. Once the subprocess makes a connection to the user process, no further connections are accepted. In practice this happens within a second of when the user process spawns the subprocess. This seems to have limited exploitablility. If further security is desired, a random number could be passed to the subprocess for authentication upon connection. Comments appreciated! -- KBK

On Sat, 2003-07-26 at 17:53, Paul Moore wrote:

Sure, the fact that people might ask "why is Python talking to the internet?" is worrying. But surely the correct answer is to say firmly, but in the politest possible way, "it's not - whatever gave you the impression that it is, is mistaken".

Adding text to bugs.html will at least give all the help@python.org volunteers something to quickly point to that will explain away all the FUD. :) -Barry

On Sunday 27 July 2003 00:05, Martin v. Löwis wrote:

Alex Martelli wrote:

...

"release candidates" are supposed to help us find critical bugs AND FIX THEM before final release. I opine these bugs that we've found ARE critical enough

I completely disagree. This code has been in IDLE for quite some time. If it was a serious problem, it would have been reported before.

It's been in *idlefork* -- not in the mainstream, an official Python release. The kind of people for whom these problems are very serious -- newbies, attracting whom is crucial to Python's future -- just aren't likely to download and try arbitrary SF projects nor any release that's not "final"; the people who DO download and try SF projects and alpha/beta/rc releases -- and submit bug reports for things they dislike -- are clearly more likely to have well configured machines, avoid using "personal firewalls" that as Gerhard reminded us are in fact of dubious utility though popular, or even (as Tim Peters reports he did) investigate the sources enough to satisfy themselves that the firewall's report is bogus and not submit that as an idlefork bug. Alex

[Martin v. Löwis]

I completely disagree. This code has been in IDLE for quite some time. If it was a serious problem, it would have been reported before.

Well, variations of it have been reported to Alex, and to me (via the Tutor list), and I experienced my own Windows Moment with it. I failed to act on the warnings I got, but reflection on the Tutor list strongly suggests it's going to be a major problem on Windows. Newbies don't generally download pre-release software (except by mistake), so I take the Tutor list report from someone who did very seriously indeed. Kurt's suggestion to add a message at the top of the IDLE shell window seems adequate and very low risk.

"Tim Peters" writes:

Sorry, that one isn't a possibility. After 3 years and 50 comments and at least a dozen attempts by Tk wizards to fix it, I finally gave up on this bug report, and closed it as hopeless:

Programs using Tkinter sometimes can't shut down (Windows) http://www.python.org/sf/216289

The only known workaround is never opening Tcl/Tk clients with python.exe.

OK, I've submitted patch 778323, copied below, which opens a Tk message box. This is a relatively low risk patch: 1. One line added to PyShell to set a timeout on the socket.accept(). In the case Alex raises, it's likely the user process will block waiting for the subprocess to connect, leaving a stuck process for the user to clean up. The timeout fixes that. 2. One line added to run.py which calls the Tk error message method. This line and the method only execute when a socket error is raised and the situation is already pretty bleak. Tested on XP and RH6.2. The text printed to sys.__stderr__ would get removed at 2.3.1. -- KBK Index: PyShell.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/PyShell.py,v retrieving revision 1.81 diff -c -p -r1.81 PyShell.py *** PyShell.py 27 Jul 2003 03:24:18 -0000 1.81 --- PyShell.py 27 Jul 2003 03:41:14 -0000 *************** class ModifiedInterpreter(InteractiveInt *** 349,354 **** --- 349,356 ---- sys.exit() self.spawn_subprocess() # Accept the connection from the Python execution server + ## XXX 26Jul03 KBK Should raise a Tk exception message on timeout + self.rpcclt.listening_sock.settimeout(20) self.rpcclt.accept() self.rpcclt.register("stdin", self.tkconsole) self.rpcclt.register("stdout", self.tkconsole.stdout) Index: run.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/run.py,v retrieving revision 1.25 diff -c -p -r1.25 run.py *** run.py 22 Jun 2003 07:52:56 -0000 1.25 --- run.py 27 Jul 2003 03:41:30 -0000 *************** def manage_socket(address): *** 103,112 **** --- 103,122 ---- + err[1] + ", retrying...." else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." + show_socket_error(err) global exit_now exit_now = True return server.handle_request() # A single request only + + def show_socket_error(err): + import Tkinter + import tkMessageBox + root = Tkinter.Tk() + root.withdraw() + msg = "Can't Connect to IDLE User Process: %s" + tkMessageBox.showerror("IDLE Subprocess Error", msg % err[1], parent=root) + root.destroy() def print_exception(): flush_stdout() Index: NEWS.txt =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/NEWS.txt,v retrieving revision 1.23 diff -c -p -r1.23 NEWS.txt *** NEWS.txt 27 Jul 2003 03:24:18 -0000 1.23 --- NEWS.txt 27 Jul 2003 04:02:46 -0000 *************** What's New in IDLE 1.0? *** 3,8 **** --- 3,11 ---- *Release date: 29-Jul-2003* + - Added a Tk error dialog to inform the user if the subprocess can't connect + to the user GUI process. Added a timeout to the latter's listening socket. + - Added a banner to the shell discussimg warnings possibly raised by personal firewall software. Added same comment to README.txt.

[Kurt B. Kaiser]

... A very restricted change to the code would be add the following to the banner printed at the top of the shell when it starts (the socket connection isn't made until the shell window opens):

*************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ***************************************************************

This involves an addition to PyShell.py:PyShell.begin(), line 873.

In addition, the .../idlelib/README.txt would be updated with the same message w/o the asterisks.

I think that's a great idea, and is all we really need for 2.3 final. Barry is the release manager now, so the final call is his, but I'm +1 on it.

These are not the final solutions. A pop-up for #1, everytime, and a pop-up for #2 on first use would be introduced into 2.3.1. The above banner could be retained even after the popup is implemented, though I'm -1 on that.

Final solutions can be argued over after the final release. On a box with multiple profiles, is the proposed "first use" pop-up relative to the first time IDLE is run, or to the first time a specific user runs IDLE? I don't even want to know the answer now (no time for this now), just trying to suggest there may be issues with clever approaches. Dirt-dumb is all we can consider for 2.3 final.

On Sat, Jul 26, 2003, Kurt B. Kaiser wrote:

"Tim Peters" writes:

...

[Kurt B. Kaiser]

...

... A very restricted change to the code would be add the following to the banner printed at the top of the shell when it starts (the socket connection isn't made until the shell window opens):

*************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ***************************************************************

This involves an addition to PyShell.py:PyShell.begin(), line 873.

In addition, the .../idlelib/README.txt would be updated with the same message w/o the asterisks.

I think that's a great idea, and is all we really need for 2.3 final. Barry is the release manager now, so the final call is his, but I'm +1 on it.

Submitted as Patch 778286, assigned to Barry.

Go ahead and commit it; Barry's probably going to approve it, and it's one less thing for him to do. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz

Tim Peters wrote:

[Kurt B. Kaiser]

...

... A very restricted change to the code would be add the following to the banner printed at the top of the shell when it starts (the socket connection isn't made until the shell window opens):

*************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ***************************************************************

This involves an addition to PyShell.py:PyShell.begin(), line 873.

In addition, the .../idlelib/README.txt would be updated with the same message w/o the asterisks.

I think that's a great idea, and is all we really need for 2.3 final. Barry is the release manager now, so the final call is his, but I'm +1 on it.

After seeing this thread, I experimented with 2.3c2 IDLE on my machine (Windows XP, with the free ZoneAlarm installed). The ZoneAlarm warning comes up *before* the Python Shell window opens - the shell Window doesn't open until after I click 'Yes'. If I click "No", the shell window never appears at all. So Kurt's suggestion may not help, if the firewall intercepts the outgoing connection _before_ the above message is made visible to the user. (I suspect Zone Alarm halts the entire process responsible for initiating the connection request) Details on the ZoneAlarm warning: The Destination IP is given as "127.0.0.1: Port 8833" and the connecting application is listed as "pythonw.exe". (I imagine the port number will vary for different configurations and so forth - at the moment its consistent for me, but that is no doubt due to the particular applications I currently happen to have running). The IP address and application name may be useful in the warnings for non-technical users (after all, they clicked on an "IDLE" icon - they may not have any idea what "pythonw" is) Unsurprisingly, Zone Alarm's Alert Advisor says nothing about what the program is, or why it is trying to access the network. I've submitted some feedback to them, suggesting it might be useful to point out in Alert Advisor that '127.0.0.1' means the connection is being made directly back to the current computer. This doesn't help anyone using a different firewall application, though (and it is questionable whether or not Zonelabs will do anything about it, anyway - it must be an issue they have come across before). Regards, Nick. -- Nick Coghlan | Brisbane, Australia ICQ#: 68854767 | ncoghlan@email.com Mobile: 0409 573 268 | http://www.talkinboutstuff.net "Let go your prejudices, lest they limit your thoughts and actions."

On Sat, 2003-07-26 at 19:54, Tim Peters wrote:

[Kurt B. Kaiser]

...

... A very restricted change to the code would be add the following to the banner printed at the top of the shell when it starts (the socket connection isn't made until the shell window opens):

*************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ***************************************************************

This involves an addition to PyShell.py:PyShell.begin(), line 873.

In addition, the .../idlelib/README.txt would be updated with the same message w/o the asterisks.

I think that's a great idea, and is all we really need for 2.3 final. Barry is the release manager now, so the final call is his, but I'm +1 on it.

Tim again proves his superior channeling skills. +1 and please go ahead and check this in. -Barry