User: Password:
|
|
Subscribe / Log in / New account

Wayland and Weston 0.99.0 snapshots released

Wayland and Weston 0.99.0 snapshots released

Posted Oct 19, 2012 14:28 UTC (Fri) by drag (subscriber, #31333)
In reply to: Wayland and Weston 0.99.0 snapshots released by ncm
Parent article: Wayland and Weston 0.99.0 snapshots released

Ideally it for network-ability Wayland should have:

1. Graphic outputs over the network (as discussed above)
2. Audio output over the network (TCP support in Pulseaudio is very effective)
3. Copy-n-paste over the network. Hopefully some standard for clipboard managers will be implemented. Hopefully HTML-aware in a manner similar to Windows.
4. Notifications over the network.
5. File transfer support.
6. Some sort of thing for supporting weird input devices. Like USB support for generic devices.. things for special input support like game devices or accessability devices. I don't know.
7. Some lovely way to securely tunnel it all. SSH would be great I expect.

I would be happy when 1 and 3 since I can fudge PA to work well for 2 and I have no problem with scp. I am just saying since this is the sort of functionality people expect to be present for remote desktops since it's already present in most competing products.


(Log in to post comments)

Wayland and Weston 0.99.0 snapshots released

Posted Oct 19, 2012 15:02 UTC (Fri) by njs (guest, #40338) [Link]

While those are all nice features for a remote access protocol, a lot of them are orthogonal to Wayland. There's no reason Wayland would be in the loop for USB forwarding, that's between the remote display software and udev or whatever. And Wayland isn't going to do any audio output, though it'd be nice if there were a way to bundle together audio/graphic/dbus session addresses so that you could point an app at a coherent remote session by setting one environment variable instead of messing about with forwarding all of these protocols separately. The annoying features are going to be things like:

Sane *async* protocol for cut-and-paste format negotiation/data transfer

Custom cursor updating

Communicating desktop geometry (including multiple monitors at different resolutions, etc.)

Relationships between windows ("this window is a modal pop-up to that window")

Mapping windows to processes ("this process appears to have frozen; kill it?")

etc. There's just a ton of fiddly details like this.

Wayland and Weston 0.99.0 snapshots released

Posted Oct 25, 2012 4:14 UTC (Thu) by amtota (subscriber, #4012) [Link]

> And Wayland isn't going to do any audio output, though it'd be nice if there were a way to bundle together audio/graphic/dbus session addresses so that you could point an app at a coherent remote session by setting one environment variable instead of messing about with forwarding all of these protocols separately.
xpra.org deals with graphics and dbus notifications.
dbus was not designed to be networked however, so forwarding any more dbus based protocols would need to be done on a per case basis unfortunately.
As for audio, see my other reply: PA is not suitable without a fair amount of work (compression, support for disconnection, etc)
> Sane *async* protocol for cut-and-paste format negotiation/data transfer
xpra does that (mostly reasonably well too now)
> Custom cursor updating
xpra does that
> Communicating desktop geometry (including multiple monitors at different resolutions, etc.)
Planned.
> Relationships between windows ("this window is a modal pop-up to that window")
xpra tries to do that (not easy - not even do-able in some cases since we cannot tell the client's window manager to "group" windows together so they move together - but we manage ok)
> Mapping windows to processes ("this process appears to have frozen; kill it?")
Not supported yet (hard I think)
> etc. There's just a ton of fiddly details like this.
Indeed!

Wayland and Weston 0.99.0 snapshots released

Posted Oct 25, 2012 11:36 UTC (Thu) by njs (guest, #40338) [Link]

> > Sane *async* protocol for cut-and-paste format negotiation/data transfer
>xpra does that (mostly reasonably well too now)

I know (I wrote it, remember ;-)), but last I checked it required a horror-show of manually tracking nested GTK mainloops. (Actually I'd love to see the code if you've managed to fix that.) My point was that who-ever's doing Wayland remoting stuff should try to avoid getting stuck with such nonsense.

> xpra tries to do that (not easy - not even do-able in some cases since we cannot tell the client's window manager to "group" windows together so they move together - but we manage ok)

Actually I think you probably do support the example I gave in this message (attaching a modal pop-up to its parent), since that's in ICCCM/EWMH; its menus and other override-redirect stuff that's really broken in X.

> > Mapping windows to processes ("this process appears to have frozen; kill it?")
> Not supported yet (hard I think)

This is really easy actually, see _NET_WM_{PING,PID,HOSTNAME) (IIRC); I'm pretty sure there's some vestigial support in the code already. The only tricky part is giving it a useful UI on the client side, but you have a systray applet to hang UI off of now, right...?

Wayland and Weston 0.99.0 snapshots released

Posted Oct 26, 2012 3:58 UTC (Fri) by amtota (subscriber, #4012) [Link]

> I know (I wrote it, remember ;-)),
Hah, hi Nathaniel! (aka 'njs')

> horror-show of manually tracking nested GTK mainloops
It's still there :(
I wanted to replace it with something more like twisted's "deferred", but haven't got around to it. There were a number of issues in the clipboard code, but this one has not risen to the top of the never ending todo list yet..

> (...) its menus and other override-redirect stuff that's really broken in X.
Yes, what we've added is more of a hack for OR menus, to ensure they move with their parent.

> This is really easy actually, see _NET_WM_{PING,PID,HOSTNAME) (IIRC);
> I'm pretty sure there's some vestigial support in the code already. The only tricky part is giving it a useful UI on the client side, but you have a systray applet to hang UI off of now, right...?
Yes, and it is planned. A related, and more urgent work item along those lines is dealing with dropped connections so that the client windows start showing the user that something is wrong before they start clicking repeatedly on a window which is no longer connected to its server, or not responding. (greying them out or something)

network-ability Wayland should have: most of those are in xpra

Posted Oct 25, 2012 4:08 UTC (Thu) by amtota (subscriber, #4012) [Link]

> 1. Graphic outputs over the network (as discussed above)
See xpra.org
> 2. Audio output over the network (TCP support in Pulseaudio is very effective)
I beg to differ, it is very bandwidth heavy, around 4MBps by default.
xpra supports that (setting up the X11 cookie etc), but it would need audio compression to be really useful. Also, the default pa tcp mode does not support disconnection/re-connection...
> 3. Copy-n-paste over the network. Hopefully some standard for clipboard managers will be implemented. Hopefully HTML-aware in a manner similar to Windows.
xpra does that
> 4. Notifications over the network.
xpra does that - tray icon support is planned
> 5. File transfer support.
Not implemented - not sure we want to either.
> 6. Some sort of thing for supporting weird input devices. Like USB support for generic devices.. things for special input support like game devices or accessability devices. I don't know.
On the todo list so we can support things like pressure sensitive devices over the network (ie: android clients)
> 7. Some lovely way to securely tunnel it all. SSH would be great I expect.
xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)

network-ability Wayland should have: most of those are in xpra

Posted Oct 25, 2012 13:34 UTC (Thu) by njs (guest, #40338) [Link]

> I beg to differ, it is very bandwidth heavy, around 4MBps by default. xpra supports that (setting up the X11 cookie etc), but it would need audio compression to be really useful. Also, the default pa tcp mode does not support disconnection/re-connection...

In principle even this would be fixable with some work (either by fixing the PA TCP mode or by running a PA daemon on the server and loading some custom 'xpra sink'), but the real problem is multiplexing latency-sensitive audio + screen updates over an SSH channel over TCP while avoiding audio dropouts. Maybe once bufferbloat is fixed this will be more doable, but for now it's a very difficult bit of network engineering.

> xpra supports ssh and will have an AES/SPEKE secure tcp mode in the next release (probably)

While I am sort of amused to see my predictions from years ago coming true[1], it's still true that ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting, but it is important that you NOT DO THIS IT WILL NOT BE SECURE I PROMISE YOU WILL BE LYING TO YOUR USERS. I know SSH and TLS are both obnoxious to work with but EVERYTHING ELSE IS SNAKE OIL THERE IS NO-ONE ALIVE WHO IS SMART ENOUGH TO DO WHAT YOU ARE DOING SO STOP IT.

...goodness sakes, 2 minutes of googling suggests that TLS-SRP is even reasonably well supported these days. Use that. Please.

[1] "how do I know that the next person won't want even more assurances, like encryption or MITM protection or whatever? That will *definitely* spiral out of our ability to get right." - http://lists.partiwm.org/pipermail/parti-discuss/2009-Jun...

network-ability Wayland should have: most of those are in xpra

Posted Oct 26, 2012 3:50 UTC (Fri) by amtota (subscriber, #4012) [Link]

> In principle even this would be fixable with some work (either by fixing the PA TCP mode or by running a PA daemon on the server and loading some custom 'xpra sink'), but the real problem is multiplexing latency-sensitive audio + screen updates over an SSH channel over TCP while avoiding audio dropouts. Maybe once bufferbloat is fixed this will be more doable, but for now it's a very difficult bit of network engineering.
In winswitch, I've solved this by doing pretty much that: starting a decicated PA server per session (which is not trivial if you launch more than one per user) and then compressing the stream over TCP sockets (yikes) via gstreamer pipelines (with buffering and all)
The problem with xpra is that I see this as being out of scope: do one thing and do it well.

> ROLLING YOUR OWN TRANSPORT CRYPTO IS A STUPID IDIOTIC IDEA AND YOU SHOULD NOT DO IT. Sorry for shouting (...)
Please feel free to review the code once it is finished (it isn't), some already have already provided comments:
https://www.xpra.org/trac/ticket/198

> I know SSH and TLS are both obnoxious to work with (...)
Indeed. And more importantly, it is a different security model altogether: one where you trust an authority (or just inspect manually) to verify the authenticity of the host. We aren't interested in that. If that is what you want, stick with SSH, or use OpenVPN.

> EVERYTHING ELSE IS SNAKE OIL (...)
I think the authors of SPEKE would beg to differ...

> That will *definitely* spiral out of our ability to get right."
Well, let's agree to disagree. Secure key exchange is not rocket science, it was quite a new thing 15 years ago, but things have moved on.
Please do consider the differences between the ssh/tls model and speke.. these do not address the same concerns. (and I'll admit there may well be difficulties in explaining those differences to users)

network-ability Wayland should have: most of those are in xpra

Posted Oct 26, 2012 14:17 UTC (Fri) by njs (guest, #40338) [Link]

> Please feel free to review the code once it is finished (it isn't), some already have already provided comments:

This is only useful if you can convince as many people to review your code as have reviewed SSH/TLS. Those protocols both contained bugs which survived dozens of man-years of review. You are not smarter than the entire cryptographic community. Have you read your Ferguson & Schneier (& Kohno)? What's your rekeying time? Do you know what that is and why it matters? Now that I've said that you can look it up and patch one obvious hole, but there will still be a dozen more.

> I think the authors of SPEKE would beg to differ...

WTF, do you not even understand the difference between a crypto primitive and a crypto protocol? SPEKE is a fine primitive (well, there are better ones, but that's actually besides the point). But it doesn't matter if you choose good primitives. If design your own protocol YOU WILL FUCK IT UP AND CHALLENGING PEOPLE TO REVIEW IT WILL NOT SAVE YOU.

Most snake oil vendors honestly believe that their code is great! And advertise them by boasting about using cool primitives (AES! SPEKE! XX-bits! never mind that they're used insecurely!). And then when someone point this out, the snake oil vendor always responds by challenging them to review the code and point out specific problems. Srsly you're exhibiting the classic symptoms. Stop and think about it. Spreading bad crypto is a sin.

> Please do consider the differences between the ssh/tls model and speke

Please read my fucking message. I said you should use TLS-SRP. That has the same model as the protocol you are ineptly trying to design. Yes, it requires you to deal with the gnutls api instead of playing around with fun maths, but on the other hand IT IS DESIGNED AND IMPLEMENTED BY PEOPLE WHO KNOW WHAT THEY ARE DOING AND IT WILL ACTUALLY FUCKING WORK.

(Just one example - SPEKE requires the server store passwords in plain text, which we've had *plenty* of evidence lately is a terrible idea. SRP avoids this problem.)

network-ability Wayland should have: most of those are in xpra

Posted Oct 27, 2012 1:45 UTC (Sat) by amtota (subscriber, #4012) [Link]

> Please read my fucking message
Sorry, after all the shouting and swearing, I stopped. Maybe some other time.

network-ability Wayland should have: most of those are in xpra

Posted Oct 27, 2012 10:11 UTC (Sat) by njs (guest, #40338) [Link]

Heh. I swear because I care... and because every time I've explained this before, you've just ignored the main points completely. So I was hoping that might get you to pay attention.

Obviously though if you are determined not to listen when people warn you that you are making a serious mistake, then that's ultimately your decision.

network-ability Wayland should have: most of those are in xpra

Posted Oct 28, 2012 17:31 UTC (Sun) by nix (subscriber, #2304) [Link]

Srsly, he's right. This way lies disaster, no matter how smart you are. Programming Satan's computer, and all that. It's ever so much better an idea to use someone else's code for this, and gnutls does work and does get review.

TLS-SRP (as opposed to plain TLS) is suitable?

Posted Feb 19, 2015 1:34 UTC (Thu) by gmatht (subscriber, #58961) [Link]

Minus the shouting the concern seems to be that your security model sounds a lot like that of the already existing TLS-SRP (as opposed to plain TLS). For example:
TLS-SRP provides mutual authentication (the client and server both authenticate each other), while TLS with server certificates only authenticates the server to the client. Client certificates can authenticate the client to the server, but it may be easier for a user to remember a password than to install a certificate. -- Wikipedia
Any comments on the difference between your security model and that of TLS-SRP?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds