Re: [Tigervnc-devel] Zlib Protocol
On Mon, 21 Nov 2011 16:20:52 -0600 Matt B empe...@mightypenguin.org wrote: Hi all, Working on getting zlib and related protocols working on noVNC and have hit an issue. The first zlib packet seems to inflate and draw correctly, but the second or third zlib packet I get is a 32 or 64 byte piece of compressed data that I'm not sure what to do with. It inflates to around 610ish bytes. Any ideas? I haven't looked at the code, but have you made sure you keep the zlib state between packets? The zlib stream is generally never restarted during the lifetime of a connection, so you need to keep it around for multiple updates. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Security for multiple client types
Hi, I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). Is this a big problem? Can I make it better somehow, perhaps by creating a dynamic firewall rule that only allows VNC client access from the IP address given during a previous HTTPS authentication? Any thoughts welcome. Thanks, Dan G -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Security for multiple client types
On Tue, Nov 22, 2011 at 05:39:54PM +, Dan Garton wrote: I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). Is this a big problem? Can I make it better somehow, perhaps by creating a dynamic firewall rule that only allows VNC client access from the IP address given during a previous HTTPS authentication? You will not get any security this way. Without encryption, all keyboard input is sent unencrypted. Please don't waste your time with such pseudo security solutions - you should better invest them into implementing encryption in mobile clients. Regards, Martin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Security for multiple client types
On 11/22/11 3:07 PM, Martin Koegler wrote: On Tue, Nov 22, 2011 at 05:39:54PM +, Dan Garton wrote: I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). To expand upon what Martin said, SecurityType=VncAuth (VNC Password Authentication) is the classic way of authenticating with VNC servers, and every mobile VNC client I've seen supports that. However, it's not really secure. The password is sent using DES3, so it can't be casually sniffed, but the session is not encrypted at all once the password is transmitted, so any other passwords you type while connected will be completely readable. Probably not a big deal if you're running within a secure corporate network without root access, but outside of a firewall, it's an issue. The issue with VNC on iOS is that Apple won't allow any GPL-licensed apps in the App Store, so that effectively eliminates one's ability to leverage code from TigerVNC (or most other VNC code bases) in an iPhone app. It probably prevents one from using LGPL-licensed libraries such as GnuTLS as well (TigerVNC uses GnuTLS to implement its built-in encryption.) The terms of the LGPL are such that you would have to provide source for the library as well as object files for the rest of the VNC viewer, and my understanding is that any such viral provisions are incompatible with the App Store. Android would be an easier target. I don't think it already has GnuTLS, so it would probably be necessary to build those libraries and statically link against them, but the Android Market does allow GPL'ed software, so it would be theoretically possible to extend one of the existing Android VNC clients. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3441264 ] FLTK Viewer Clipboard Regression
Bug Tracker item #3441264, was opened at 2011-11-22 14:53 Message generated for change (Tracker Item Submitted) made by ragoley You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126848aid=3441264group_id=254363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert (ragoley) Assigned to: Pierre Ossman (ossman_) Summary: FLTK Viewer Clipboard Regression Initial Comment: All testing has been done using DRC's 11-08-2011 builds for the server and the FLTK viewer. Older TigerVNC 1.1 viewer used for regression testing. The FLTK viewer copies the clipboard from the Xvnc server just fine. It does not copy to it at all though. Somehow, the Xvnc clipboard is never updated with the contents of the Windows clipboard. The vncconfig utility is running with all clipboard options enabled. If you use the 1.1 viewer to connect to the same Xvnc/vncconfig setup, it works perfectly both from the Xvnc to the Windows clipboard and from the Windows clipboard to the Xvnc clipboard/cutbuffer. I am not sure when this regression started as the FLTK viewer was basically unusable for day to day work because of the inverted mouse cursor. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126848aid=3441264group_id=254363 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3336716 ] mouse reversed
Bug Tracker item #3336716, was opened at 2011-06-27 01:36 Message generated for change (Comment added) made by ragoley You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126848aid=3336716group_id=254363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: FLTK viewer Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: tatanka (timtatanka) Assigned to: Pierre Ossman (ossman_) Summary: mouse reversed Initial Comment: Using DRC's build, I had a vertically reversed mouse-image. Changing the mouse theme (KDE) doesn't help. -- Comment By: Robert (ragoley) Date: 2011-11-22 15:12 Message: I have done further testing after timtatanka's comments. He is correct. I spoke too soon about closing this ticket. I did most of my testing and work that day on OSX. I switched over to confirm that the mouse cursor was no longer inverted and indeed it is not. It does not change either though. Using the OSX viewer, the mouse cursor changes to the various related images as needed. For example, when your mouse hovers over the edge of a window in a VNC session, it changes to the window manager's image for dragging or resizing the window. This helps to know when resizing is possible with the current mouse position. That does not happen when using the FLTK viewer from trunk. The exact same image always displays no matter the window context for the mouse. This was tested with DRC's 11-08-2011 build. -- Comment By: tatanka (timtatanka) Date: 2011-11-09 01:29 Message: The mouse cursor never changes shape now. This can't be the purpose neither... -- Comment By: Robert (ragoley) Date: 2011-11-08 08:23 Message: This appears to be resolve in DRC's 11-8-2011 build. This can be closed now. -- Comment By: tatanka (timtatanka) Date: 2011-09-27 01:42 Message: I tried the latest build, but the problem is still present. -- Comment By: D. R. Commander (dcommander) Date: 2011-09-26 15:19 Message: Please retest issue with latest build (9/26/11) http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases and close this item if fixed. -- Comment By: Pierre Ossman (cendossm) Date: 2011-09-26 05:49 Message: Should be fixed in trunk now. I don't know if DRC has a new build available? -- Comment By: Robert (ragoley) Date: 2011-08-25 11:09 Message: This is still a problem with DRC's latest build for windows. What I meant by the mouse image is the graphic image used for the pointer. In this case, the arrow that should be pointing to the top left is actually pointing to the bottom left. The cursor image looks flipped upside down. Picturing the cursor as a square that wraps the arrow image used for the cursor, the focus point is the top left corner of the arrow image. The actual point of the arrow image is in the bottom left of that square. Basically, the arrow image is upside down and the focus point is not. -- Comment By: Robert (ragoley) Date: 2011-07-05 08:05 Message: I am having the same problem with DRC's build. The mouse cursor is upside down. It still works but you have to use the wrong end of the cursor image. -- Comment By: tatanka (timtatanka) Date: 2011-06-27 02:07 Message: I hope this is something in the tigervnc code? Otherwise I'm not able to do this... -- Comment By: Pierre Ossman (ossman_) Date: 2011-06-27 02:00 Message: My bad. This is a bug in the FLTK cursor code. I forgot that Windows likes everything upside down, so you have to specify a negative height on that platform when creating the cursor. -- Comment By: tatanka (timtatanka) Date: 2011-06-27 01:51 Message: Yes, the cursor shape. It looks like it is still working the correct way, because the place the click is registered is somewhere above the cursor. -- Comment By: D. R. Commander (dcommander) Date: 2011-06-27 01:38 Message: Please indicate what you mean by mouse image. Do you mean your cursor shape is incorrect? -- You can respond by visiting:
