Winpdb - A Platform Independent Python Debugger Security
As in most Python debuggers, in Winpdb, communication between Debugger and Debuggee is done via Internet sockets. This communication is protected with a password which is used as the basis for a hashing/encryption key. Such keys are never stronger than the password itself, and a short or simple password means a weak key.
Authenticated and Encrypted Communication
By default the socket communication is authenticated and optionally encrypted. Encryption is performed only if the python-crypto Cryptographic Toolkit is installed. Encryption can be forced with the -e command line flag. In this mode a debugge will only accept encrypted connections.
http://www.amk.ca/python/code/crypto
Automatic Passwords
If a debug session is launched from Winpdb without having set a password, a pseudo random password will be generated transparently, without interrupting the user.
Remote Connections Denial
By default, the debuggee denies remote connections, and only accepts debugger connections from the local host. However, the debuggee can be set to accept connections from remote machines with the -r flag.
Command Line Flags:
-e - Force encrypted connections -p <password> - Set communication password -r - Allow connections from remote machines.
The password flag is only supported on Windows systems.
Console Commands:
remote - Get or set the allow remote connections mode.
password - Get or set the password that governs connections.
GUI control:
Set Password
To set the password, click File->Password
If a password has not been set when the attach command is first invoked, the password dialog will pop up automatically.
This package has too many external dependencies. My next thought after the xterm problem was to use the remote debugging feature to debug from my desktop machine which does have xterm. But now it wants the AMK crypto package. I guess I may have better luck installing that, so I’ll give it a try. But it would be better if the package were self contained. Maybe instead of AMK crypto, it could use TLS Lite (www.trevp.com/tlslite) which is pure Python. If and when tlslite gets real x509 support, the debugger could authenticate the remote peer with a client certificate.
Meanwhile, how about a mode that eliminates the crypto and instead listens on a local socket. Then I\\\\\\\’d use ssh port forwarding to debug securely from a remote machine.
Also, this comment form is far too smart for its own good with javascript. I keep getting reload failures, the submit button being greyed out, etc. How about just using straightforward html.
On further thought I suggest removing the crypto completely. Just listen on a loopback port and authenticate with a password. For remote debugging, get security by using ssh or stunnel port forwarding.
The crypto package is optional. Winpdb will not force it unless you use the -e command line flag. When it is not present connections are password authenticated only.
You can also use winpdb over ssh if you forward port 51000 (and 51001 if needed).
Great, thanks! I’m trying that. But rpdb2 still tries to start a local xterm, is there some reason for that? It’s really causing me grief. I think I understand why I can’t forward the X port to my desktop, it has to do with screwy configuration on the remote side, but there’s not much I can do about that for now. I also can’t access the /dev/pts directory needed to run screen. I don’t have any sense of why the local xterm is needed, if the winpdb ui is on a remote machine. Can I disable it somehow?
See the comments on the “Launch Time” documentation page for an explanation.