On Tue, Nov 10, 2009 at 8:41 AM, Antoine Martin <[email protected]> wrote: > Nathaniel Smith wrote: >> Okay... but that patch just adds a try/catch around the initial client >> socket creation, and only catches socket errors. It only affects the >> initial connection, and even then it doesn't affect SIGINT handling... > Yes, this patch (rebased): > http://xpra.devloop.org.uk/patches/v0.0.8pre/avoid-apport-whenkilled-againstmainline.patch > Prevents apport from firing if you get the target wrong.
Ah, that makes much more sense (though I still can't reproduce the part where apport gets triggered). The patch as written is a little weird: - app = XpraClient(sock, opts.compression_level) ??? But I've committed the gist of it, I think. >> Okay, I just committed the version where it shows the actual machine >> where the app is running by default :-). Do you still care about the >> command line option, given that? > Actually yes, it can be a lot more relevant to name a session (purpose) > than its machine (location). Okay, what should that look like? A parameter to 'xpra start'? How should it be displayed to the user? 'Emacs (in <session name> on <host>, via xpra)', maybe? > This one would make my life soooo much easier, and should be totally > uncontroversial: > http://xpra.devloop.org.uk/patches/v0.0.8pre/mswindows-move-eventcode.patch Actually, there's at least one very subtle but serious bug in it :-/ (wimpiggy.util should not import gtk, because importing gtk has side effects: http://lists.partiwm.org/pipermail/parti-discuss/2008-September/000041.html http://lists.partiwm.org/pipermail/parti-discuss/2008-September/000042.html ) Can you remind me what exactly this patch is accomplishing? >> All I mean is that TCP is never going to be as secure as ssh, and in >> most situations will be substantially less secure, > Hmmm, we'll have to agree to disagree on this one. > Having to hand out SSH logins simply to bind to a port has its own > security cost/impact. Yes, that's a trade-off. We are talking about a system for giving users direct access to programs running on the host, though; it is pretty traditional that this might require creating them an account. (In practice I would *certainly* not trust random X programs to be secure against an adversarial user, and would want to run them under a special account anyway as a sandbox.) > And HMAC is very robust (yet simple to implement), despite the > weaknesses in MD5/SHA-1: > http://www.ietf.org/mail-archive/web/cfrg/current/msg00527.html > "In particular, known collisions (for KNOWN IVs) in the underlying hash > functions are IRRLEVANT to the security of HMAC." Yes, of course. The question is not whether HMAC is secure, it's whether *our implementation* would be secure against *the attacks we care about*. And if it is, then there's the question of whether it's worth the code and support costs. >> and that very few >> users have the technical knowledge to make an informed judgment >> between them -- yet the option is supported and documented, so they >> have to make such a judgment anyway, > I don't think they do. The default is SSH, if they choose to use TCP > then it is fair to assume that they at least understand the difference > between the two. The *nix philosophy is to give you enough rope. > If they choose a stupid/short password, the same reasoning applies. I'm not sure that is the unix philosophy (doesn't appear in any of the nice discussions listed at http://en.wikipedia.org/wiki/Unix_philosophy , for instance), but even if it is, then oh well, I disagree with the unix philosophy. I'm not sure you want to make this a philosophical argument; those are hard to win :-). >> and some will get it wrong. (I've >> talked to at least one person on IRC who AFAICT was using TCP because >> it must be faster. > On LANs (1GBit or higher), this would make sense. I will try to find the > time to run some benchmarks on 100MBit. The bottleneck will be in our code, not ssh. > Another point I forgot to mention is startup speed, the SSH > handshake/login sequence can be quite slow. TCP is almost instantenuous. But you want to add steps to the TCP handshake/login sequence to make it more secure :-). The ssh handshake is slow because authentication etc. require round trips. > Also, bear in mind that a lot of thin clients don't have a lot of CPU > resources (hence the use of remote displays), so taxing the CPU is > generally a last resort, and with SSH (even with the lowest compression) > you will add that extra cost. Why would a thin client run xpra? xpra is for apps, not desktops, you run xpra on the same server that runs your other apps. >> Let's stop talking hypotheticals. When you, personally, want to log >> into a remote machine over a secured network, do you use ssh or >> telnet? > Do you prefer apples or oranges? ;) > >> Do you, personally, insist that sysadmins install and support telnet >> servers, because you refuse to use ssh over secure networks? > Have you ever tried explaining what a public/private key is to an > average MS Windows user? Uh... oranges, no, and WTF? These are simple factual questions that you certainly know the answer to. Why not just type "yes" or "no"? >> If it isn't really secured, enough so that you do need password >> support, then how do we know it is secure enough that you don't need >> the many other security features ssh provides? > The one thing I have reservations on is the ability for someone snooping > on the network to replay the screen redraws on their own machine. This > is one thing SSH prevents that plain TCP simply cannot do. Also session hijacking of various sorts. >> Right now, to me, this seems like the only real argument. But this is >> so far outside xpra's core use case, and describes a situation that is >> so likely to require special infrastructure *anyway*, that I don't >> find it very convincing on its own. > The only special infrastructure is an application to serve, think thin > clients/kiosks types. Infrastructure = special setup work. I think there are many applications that are not thin clients or kiosks, and work must be done to turn them into such. >>> * Win32 and SSH don't get on. Putty/Plink is no go and openssh would >>> require cygwin. Keep it simple. >> >> AFAIK, I've made them "go" -- though I'm still waiting for someone to >> confirm that, see the other thread. Is there something I'm missing? > I'll try to find the time to test that soon... Thanks. -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
