[prev in list] [next in list] [prev in thread] [next in thread] 

List:       parti-discuss
Subject:    Re: [Parti-discuss] patches
From:       Antoine Martin <antoine () nagafix ! co ! uk>
Date:       2009-11-11 8:42:21
Message-ID: 4AFA78ED.6010105 () nagafix ! co ! uk
[Download RAW message or body]

[snip]

>>> 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?

That would be fine I think. The (via xpra) part could be omitted as it
would be pretty clear from the rest of the title that it is not your
average VIM session. ;)
And it does not add any value. (except maybe publicity)

>> 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?
Hah, ok. All it does is ensure that every part of the code that uses
get_display_for (and also the event stuff) does not depend on
wimpiggy.lowlevel as this is not available on win32.
This leaves just the xlib stuff in lowlevel, which is only used by the
server part (and win32 does not care about that).

Maybe move the get_display_for to wimpiggy.event too?
Let me know if that's acceptable and I'll send an updated patch.
The part that moves the event stuff to wimpiggy.event should be fine as
it is, right?

>>> 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.
The only commonly used security measure not present in the patch that I
sent is the connection throttling, which prevents DoS and reduces the
chances of a being able to brute force the password.

>>> 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
http://lwn.net/Articles/327141/
"Unix gives you just enough rope to hang yourself -- and then a couple
of more feet, just to be sure."

> 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.
True, I wasn't necessarily thinking in terms of bottlenecks, but SSH
will add some latency, however small that may be. And on thin/small
systems, having an extra process (using up memory, etc) and latency is
more relevant than you would think.

>> 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.
It is still an order of magnitude quicker, try it.

>> 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.
There are all sorts of thin and thinner clients out there, and the
thicker ones combine a thin local desktop with remote apps. (whether the
"thin-client" terminology still applies is open for debate)

These will typically use NX in rootless mode, or RDP>=v6, but could also
use xpra.
CPU power varies from low-power ARM/MIPS to Intel Atom and up.

>>> 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"?
Apples, because the premise of the question is biased, so giving a "yes"
or "no" answer is not helpful in this context.

>>> 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.
TCP hijacking on a secured LAN should be prevented by the network
infrastructure and not the application layer. Now, some would argue that
you need both ("security is like an onion"), but this really depends on
the profile/setup and the trade-offs you choose to make.

Antoine

>>> 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
Parti-discuss@partiwm.org
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
[prev in list] [next in list] [prev in thread] [next in thread]