Alex Martelli <aleax@aleax.it> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4