Re: [Tigervnc-devel] TigerVNC + noVNC: Security options?
On Fri, Dec 02, 2011 at 02:45:45PM +, Dan Garton wrote: I'm not aware of any transparent signon. TigerVNC only allows: * No authentification * Classic VNC authentification * Authentification with username/password (default authentification provider is the system authentification) It would be possible to extend SSecurityTLS/CSecurityTLS to send/verify client certificates and use this with X509None. This would result in a passwordless login solution based on certificates - but you would have to extend the code. Ok, I must admit this has confused me a bit. Your email at http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg01013.html suggested to me that X509None *already* allows for a passwordless login based on certificates, and you also listed the options used on both server and client sides for this. No. x509cert and x509key of the server are the crendentials, with which the server will prove its identity. x509ca + x509crl on the client are used to check the server identity. This is the same procedure, as any normal https website works. For passwordless logins, you need client certificates. The client needs a certificate and it's key and the server needs the ca + crl to verify it. gnutls has the support for this, but some glue code is missing. If you don't know the whole client certificates thing, I suggest to start reading the apache httpd mod_ssl documentation (especially SSLCACertificateFile). 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] TigerVNC + noVNC: Security options?
On Wed, Nov 30, 2011 at 06:03:36PM +, Dan Garton wrote: I have kind of answered my own question. An option seems to be to run with -SecurityTypes=VNCAuth,TLSVnc This mandates a minimum of a secure authentication stage, and then the client can be configured (but not forced) to encrypt the session traffic. No. The client may choose between one of them. Either the session is unencrypted (VNCAuth) or using the VeNcrypt+TLSVnc protocol (encrypted). I don't think that the server is NOT forcing encryption on the session is significant, as in reality all instances of user sessions will implement encryption (this could even be hard-configured on the client side ie by passing the param in the JNLP for the Java viewer). Really my only remaining issue is how to implement password-less login either with TLSVnc and doing some kind of hidden password passing with the JNLP, or by using X509Vnc I guess . I'm not aware of any transparent signon. TigerVNC only allows: * No authentification * Classic VNC authentification * Authentification with username/password (default authentification provider is the system authentification) It would be possible to extend SSecurityTLS/CSecurityTLS to send/verify client certificates and use this with X509None. This would result in a passwordless login solution based on certificates - but you would have to extend the code. I'm trying to run a TigerVNC server in my project with the following security: - encryption (to make session traffic hard to sniff) - authentication (preferably via transparent key exchange, but if necessary a password submission is possible) According to this email from Martin K back in February ( http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg01013.html ) I have these options: - TLSVnc - X509Vnc I am currently using TLSVnc fine with the bundled Java viewer. However, for non-Java-capable platforms, I need to use a different client solution, and on a tip from Brian H I have landed on noVNC ( https://github.com/kanaka/noVNC ) (noVNC doesn't do SSL natively, but can use a WebSockets proxy (websockify) which I have deployed) But I can't get it to connect to TigerVNC server running with SecurityType=TLSVnc. The noVNC developer tells me that *The problem is that your VNC server is only configured to allow VeNCrypt and noVNC only supports standard VNC auth (2).* * * But surely TLSVnc _is_ standard authentication? (as in, VNCAuth + encryption ?) VeNcrypt is protocol extentions to raise the number of supported security types to from 2^8 to 2^32. TLSVnc is an extended security type, which first does a TLS setup and then a normal VNC auth challenge respond protocol. Passing VNCAuth through a SSL-Proxy results in a different trafic than using TLSVnc, because TLSVNC sends some bytes unencrypted, has a different ID and some additional bytes are added to the protocol. 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 Tue, Nov 22, 2011 at 04:26:44PM -0600, DRC wrote: 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. Most of the adroid code is a modifed java, so he should look at our java viewer. Andorid will likely include a TLS implementation, which can be used instead of the JDK supplied variants. The message parsing/ creating code should be reusable too. 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 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
[Tigervnc-devel] [PATCH] Support more menu keys
---
V1: keysyms.* renamed to menukey.*
vncviewer/CMakeLists.txt|1 +
vncviewer/OptionsDialog.cxx | 20
vncviewer/Viewport.cxx | 12 +--
vncviewer/menukey.cxx | 71 +++
vncviewer/menukey.h | 30 ++
5 files changed, 111 insertions(+), 23 deletions(-)
create mode 100644 vncviewer/menukey.cxx
create mode 100644 vncviewer/menukey.h
diff --git a/vncviewer/CMakeLists.txt b/vncviewer/CMakeLists.txt
index 5ea0ab4..03fb9c0 100644
--- a/vncviewer/CMakeLists.txt
+++ b/vncviewer/CMakeLists.txt
@@ -4,6 +4,7 @@ include_directories(${GETTEXT_INCLUDE_DIR})
include_directories(${CMAKE_SOURCE_DIR}/common)
set(VNCVIEWER_SOURCES
buildTime.cxx
+ menukey.cxx
CConn.cxx
DesktopWindow.cxx
UserDialog.cxx
diff --git a/vncviewer/OptionsDialog.cxx b/vncviewer/OptionsDialog.cxx
index 220ca96..5fd6154 100644
--- a/vncviewer/OptionsDialog.cxx
+++ b/vncviewer/OptionsDialog.cxx
@@ -36,6 +36,7 @@
#include OptionsDialog.h
#include fltk_layout.h
#include i18n.h
+#include menukey.h
#include parameters.h
#include FL/Fl_Tabs.H
@@ -268,11 +269,9 @@ void OptionsDialog::loadOptions(void)
menuKeyChoice-value(0);
menuKeyBuf = menuKey;
- if (menuKeyBuf[0] == 'F') {
-int num = atoi(menuKeyBuf+1);
-if ((num = 1) (num = 12))
- menuKeyChoice-value(num);
- }
+ for (int i = 0; i getMenuKeySymbolCount(); i++)
+if (!strcmp(getMenuKeySymbols()[i].name, menuKeyBuf))
+ menuKeyChoice-value(i + 1);
/* Misc. */
sharedCheckbox-value(shared);
@@ -361,9 +360,7 @@ void OptionsDialog::storeOptions(void)
if (menuKeyChoice-value() == 0)
menuKey.setParam();
else {
-char buf[16];
-sprintf(buf, F%d, menuKeyChoice-value());
-menuKey.setParam(buf);
+menuKey.setParam(menuKeyChoice-text());
}
/* Misc. */
@@ -696,11 +693,8 @@ void OptionsDialog::createInputPage(int tx, int ty, int
tw, int th)
menuKeyChoice = new Fl_Choice(LBLLEFT(tx, ty, 150, CHOICE_HEIGHT, _(Menu
key)));
menuKeyChoice-add(_(None), 0, NULL, (void*)0, FL_MENU_DIVIDER);
- for (int i = 1;i = 12;i++) {
-char buf[16];
-sprintf(buf, F%d, i);
-menuKeyChoice-add(buf, 0, NULL, (void*)i, 0);
- }
+ for (int i = 0; i getMenuKeySymbolCount(); i++)
+menuKeyChoice-add(getMenuKeySymbols()[i].name, 0, NULL, 0, 0);
ty += CHOICE_HEIGHT + TIGHT_MARGIN;
diff --git a/vncviewer/Viewport.cxx b/vncviewer/Viewport.cxx
index 72de8e8..052b593 100644
--- a/vncviewer/Viewport.cxx
+++ b/vncviewer/Viewport.cxx
@@ -46,6 +46,7 @@
#include fltk_layout.h
#include parameters.h
#include keysym2ucs.h
+#include menukey.h
#include vncviewer.h
#include FL/fl_draw.H
@@ -938,16 +939,7 @@ void Viewport::popupContextMenu()
void Viewport::setMenuKey()
{
- const char *menuKeyStr;
-
- menuKeyCode = 0;
-
- menuKeyStr = menuKey;
- if (menuKeyStr[0] == 'F') {
-int num = atoi(menuKeyStr + 1);
-if ((num = 1) (num = 12))
- menuKeyCode = FL_F + num;
- }
+ menuKeyCode = getMenuKeyCode();
// Need to repopulate the context menu as it contains references to
// the menu key
diff --git a/vncviewer/menukey.cxx b/vncviewer/menukey.cxx
new file mode 100644
index 000..2e3a568
--- /dev/null
+++ b/vncviewer/menukey.cxx
@@ -0,0 +1,71 @@
+/* Copyright 2011 Martin Koegler mkoeg...@auto.tuwien.ac.at
+ * Copyright 2011 Pierre Ossman oss...@cendio.se for Cendio AB
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+
+#include string.h
+#include FL/Fl.H
+
+#include menukey.h
+#include parameters.h
+
+static const MenuKeySymbol menuSymbols[] = {
+ {F1, FL_F + 1},
+ {F2, FL_F + 2},
+ {F3, FL_F + 3},
+ {F4, FL_F + 4},
+ {F5, FL_F + 5},
+ {F6, FL_F + 6},
+ {F7, FL_F + 7},
+ {F8, FL_F + 8},
+ {F9, FL_F + 9},
+ {F10, FL_F + 10},
+ {F11, FL_F + 11},
+ {F12, FL_F + 12},
+ {Pause, FL_Pause},
+ {Print, FL_Print},
+ {Scroll_Lock, FL_Scroll_Lock},
+ {Escape, FL_Escape},
+ {Insert, FL_Insert},
+ {Delete, FL_Delete},
+ {Home, FL_Home},
+ {Page_Up, FL_Page_Up},
+ {Page_Down, FL_Page_Down},
+};
+
+int getMenuKeySymbolCount()
+{
+ return sizeof(menuSymbols)/sizeof(menuSymbols[0]);
+}
+
+const MenuKeySymbol* getMenuKeySymbols()
+{
+ return menuSymbols;
+}
+
+int getMenuKeyCode()
+{
+const char *menuKeyStr;
+int
Re: [Tigervnc-devel] [PATCH] Support more menu keys
On Fri, Aug 26, 2011 at 09:36:25AM +0200, Pierre Ossman wrote:
Looks good to me, with two notes:
vncviewer/keysyms.cxx | 71
+++
vncviewer/keysyms.h | 30 ++
Perhaps another name might be better as to not confuse this with the
X11/VNC keysym handling? menukey.*?
If you suggest a better name, I'll repost a changed patch.
+ {Scroll_Lock, FL_Scroll_Lock},
...
+ {Page_Up, FL_Page_Up},
+ {Page_Down, FL_Page_Down},
Since these strings are what's presented to the user, it would be nice
if we could have a space instead of _. I guess you did this to make it
easier to use them on the command line?
Tigervnc on unix had for years an interface for passing a menu key command line
parameter (X11 key symbols) - I tried to keep the interface the same.
What does everyone else think? Which interface is most important?
Should we perhaps have three columns to cater to both needs?
The three column approach would proably be the best.
Regards,
Martin Koegler
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] xserver / cmake issues
On Wed, Aug 24, 2011 at 11:06:06AM -0500, DRC wrote:
At any rate, I was able to reproduce the original issue after that, and
I checked in your patch to fix it.
Just one more issue, the new build system install the man-pages to $prefix/man
instead of $prefix/share/man - as used in all major distributions today.
PS:
For those, how are interrested - my prelimiary debian packages are there:
http://e9925248.users.sourceforge.net/tigervnc/
--- tigervnc-1.0.1.svn0.orig/unix/CMakeLists.txt
+++ tigervnc-1.0.1.svn0/unix/CMakeLists.txt
@@ -9,4 +9,4 @@ add_subdirectory(vncviewer)
endif()
install(PROGRAMS vncserver DESTINATION bin)
-install(FILES vncserver.man DESTINATION man/man1 RENAME vncserver.1)
+install(FILES vncserver.man DESTINATION share/man/man1 RENAME vncserver.1)
--- tigervnc-1.0.1.svn0.orig/unix/vncconfig/CMakeLists.txt
+++ tigervnc-1.0.1.svn0/unix/vncconfig/CMakeLists.txt
@@ -12,4 +12,4 @@ add_executable(vncconfig
target_link_libraries(vncconfig tx rfb network rdr ${X11_LIBRARIES})
install(TARGETS vncconfig DESTINATION bin)
-install(FILES vncconfig.man DESTINATION man/man1 RENAME vncconfig.1)
+install(FILES vncconfig.man DESTINATION share/man/man1 RENAME vncconfig.1)
--- tigervnc-1.0.1.svn0.orig/unix/vncpasswd/CMakeLists.txt
Re: [Tigervnc-devel] xserver / cmake issues
On Thu, Aug 25, 2011 at 01:57:48AM -0500, DRC wrote:
The more correct way is to provide CMake variables to override the man
directory, binary directory, etc. I personally use /opt/TigerVNC and prefer
the man pages to go in ${prefix}/man, but I agree that there needs to be an
override mechanism.
FHS specify /usr/share/man. automake have introduced $prefix/share/man as
default destination.
+1 for overrides.
Why does your source tree say 1.0.1?
I work only with trunk, so I must admit, that I don't know, what version number
it corresponds.
I justs wanted to use something low - in the final version, I'll change this.
Regards,
Martin Koegler
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH] Support more menu keys
---
vncviewer/CMakeLists.txt|1 +
vncviewer/OptionsDialog.cxx | 20
vncviewer/Viewport.cxx | 12 +--
vncviewer/keysyms.cxx | 71 +++
vncviewer/keysyms.h | 30 ++
5 files changed, 111 insertions(+), 23 deletions(-)
create mode 100644 vncviewer/keysyms.cxx
create mode 100644 vncviewer/keysyms.h
diff --git a/vncviewer/CMakeLists.txt b/vncviewer/CMakeLists.txt
index 5ea0ab4..a32c42c 100644
--- a/vncviewer/CMakeLists.txt
+++ b/vncviewer/CMakeLists.txt
@@ -4,6 +4,7 @@ include_directories(${GETTEXT_INCLUDE_DIR})
include_directories(${CMAKE_SOURCE_DIR}/common)
set(VNCVIEWER_SOURCES
buildTime.cxx
+ keysyms.cxx
CConn.cxx
DesktopWindow.cxx
UserDialog.cxx
diff --git a/vncviewer/OptionsDialog.cxx b/vncviewer/OptionsDialog.cxx
index 220ca96..6505284 100644
--- a/vncviewer/OptionsDialog.cxx
+++ b/vncviewer/OptionsDialog.cxx
@@ -36,6 +36,7 @@
#include OptionsDialog.h
#include fltk_layout.h
#include i18n.h
+#include keysyms.h
#include parameters.h
#include FL/Fl_Tabs.H
@@ -268,11 +269,9 @@ void OptionsDialog::loadOptions(void)
menuKeyChoice-value(0);
menuKeyBuf = menuKey;
- if (menuKeyBuf[0] == 'F') {
-int num = atoi(menuKeyBuf+1);
-if ((num = 1) (num = 12))
- menuKeyChoice-value(num);
- }
+ for (int i = 0; i getMenuKeySymbolCount(); i++)
+if (!strcmp(getMenuKeySymbols()[i].name, menuKeyBuf))
+ menuKeyChoice-value(i + 1);
/* Misc. */
sharedCheckbox-value(shared);
@@ -361,9 +360,7 @@ void OptionsDialog::storeOptions(void)
if (menuKeyChoice-value() == 0)
menuKey.setParam();
else {
-char buf[16];
-sprintf(buf, F%d, menuKeyChoice-value());
-menuKey.setParam(buf);
+menuKey.setParam(menuKeyChoice-text());
}
/* Misc. */
@@ -696,11 +693,8 @@ void OptionsDialog::createInputPage(int tx, int ty, int
tw, int th)
menuKeyChoice = new Fl_Choice(LBLLEFT(tx, ty, 150, CHOICE_HEIGHT, _(Menu
key)));
menuKeyChoice-add(_(None), 0, NULL, (void*)0, FL_MENU_DIVIDER);
- for (int i = 1;i = 12;i++) {
-char buf[16];
-sprintf(buf, F%d, i);
-menuKeyChoice-add(buf, 0, NULL, (void*)i, 0);
- }
+ for (int i = 0; i getMenuKeySymbolCount(); i++)
+menuKeyChoice-add(getMenuKeySymbols()[i].name, 0, NULL, 0, 0);
ty += CHOICE_HEIGHT + TIGHT_MARGIN;
diff --git a/vncviewer/Viewport.cxx b/vncviewer/Viewport.cxx
index 72de8e8..335ce2d 100644
--- a/vncviewer/Viewport.cxx
+++ b/vncviewer/Viewport.cxx
@@ -46,6 +46,7 @@
#include fltk_layout.h
#include parameters.h
#include keysym2ucs.h
+#include keysyms.h
#include vncviewer.h
#include FL/fl_draw.H
@@ -938,16 +939,7 @@ void Viewport::popupContextMenu()
void Viewport::setMenuKey()
{
- const char *menuKeyStr;
-
- menuKeyCode = 0;
-
- menuKeyStr = menuKey;
- if (menuKeyStr[0] == 'F') {
-int num = atoi(menuKeyStr + 1);
-if ((num = 1) (num = 12))
- menuKeyCode = FL_F + num;
- }
+ menuKeyCode = getMenuKeyCode();
// Need to repopulate the context menu as it contains references to
// the menu key
diff --git a/vncviewer/keysyms.cxx b/vncviewer/keysyms.cxx
new file mode 100644
index 000..240a522
--- /dev/null
+++ b/vncviewer/keysyms.cxx
@@ -0,0 +1,71 @@
+/* Copyright 2011 Martin Koegler mkoeg...@auto.tuwien.ac.at
+ * Copyright 2011 Pierre Ossman oss...@cendio.se for Cendio AB
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+
+#include string.h
+#include FL/Fl.H
+
+#include keysyms.h
+#include parameters.h
+
+static const MenuKeySymbol menuSymbols[] = {
+ {F1, FL_F + 1},
+ {F2, FL_F + 2},
+ {F3, FL_F + 3},
+ {F4, FL_F + 4},
+ {F5, FL_F + 5},
+ {F6, FL_F + 6},
+ {F7, FL_F + 7},
+ {F8, FL_F + 8},
+ {F9, FL_F + 9},
+ {F10, FL_F + 10},
+ {F11, FL_F + 11},
+ {F12, FL_F + 12},
+ {Pause, FL_Pause},
+ {Print, FL_Print},
+ {Scroll_Lock, FL_Scroll_Lock},
+ {Escape, FL_Escape},
+ {Insert, FL_Insert},
+ {Delete, FL_Delete},
+ {Home, FL_Home},
+ {Page_Up, FL_Page_Up},
+ {Page_Down, FL_Page_Down},
+};
+
+int getMenuKeySymbolCount()
+{
+ return sizeof(menuSymbols)/sizeof(menuSymbols[0]);
+}
+
+const MenuKeySymbol* getMenuKeySymbols()
+{
+ return menuSymbols;
+}
+
+int getMenuKeyCode()
+{
+const char *menuKeyStr;
+int menuKeyCode = 0;
+
+menuKeyStr
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4645] trunk/common
On Mon, Aug 22, 2011 at 02:36:57PM +0200, Pierre Ossman wrote: On Mon, 22 Aug 2011 07:08:21 -0500 DRC dcomman...@users.sourceforge.net wrote: Yuck! I am really averse to setting flags specific to building vnc.so when most people won't be building it. I'm not sure if I understand how the new system differs from the old in this respect. Didn't you have to specify --with-pic to get PIC code under autotools? Can't we do the same thing here and add a WITH_PIC CMake variable? AFAICT libtool used -fPIC by default for the convenience stuff (i.e. noinst_*). I initially intended to add a knob for it, but I changed my mind as PIC is basically harmless on x86_64 (AFAIK). In other words, since the stuff I committed should do the right thingtm in every case anyway, why would we need a setting for it? Libtool builds to version automatically: One with -fPIC and one without. While linking, libtool selectes the correct version automatically. Regards, Martin Koegler -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] xserver / cmake issues
On Tue, Aug 23, 2011 at 12:50:52PM -0500, DRC wrote:
On 8/17/11 4:01 PM, Martin Koegler wrote:
First of all, Makefile.am is missing some include path, so that a out of
source tree build fails (xserver 1.7):
--- tigervnc-1.0.1.svn0.orig/unix/xserver/hw/vnc/Makefile.am
+++ tigervnc-1.0.1.svn0/unix/xserver/hw/vnc/Makefile.am
@@ -17,7 +17,8 @@ libvnccommon_la_SOURCES = $(HDRS) vncExt
libvnccommon_la_CPPFLAGS = -DVENDOR_RELEASE=$(VENDOR_RELEASE) \
-DVENDOR_STRING=\$(VENDOR_STRING)\ -I$(TIGERVNC_SRCDIR)/common
-UHAVE_CONFIG_H \
- -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS)
-I$(includedir)/pixman-1 -I$(includedir)
+ -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS)
-I$(includedir)/pixman-1 -I$(includedir) \
+ -I$(top_srcdir)/include
bin_PROGRAMS = Xvnc
@@ -49,6 +50,7 @@ libvnc_la_CPPFLAGS = $(XVNC_CPPFLAGS) -I
-I$(top_srcdir)/hw/xfree86/common \
-I$(top_srcdir)/hw/xfree86/os-support \
-I$(top_srcdir)/hw/xfree86/os-support/bus \
+ -I$(top_srcdir)/include \
-I$(includedir)/pixman-1 -I$(includedir)
libvnc_la_LDFLAGS = -module -avoid-version
My second problem is, that it seems no longer possible to build the vnc
module. Linking the
vnc module for the Xserver leads to an linker error, because cmake only
generates non-PIC object files (eg libnetwork).
autotools+libtool did this automatically.
Martin,
I'll ask again. How are you building vnc.so?
I'm trying to build a debian package for tigervnc reusing the distribution
xserver sources.
To your commited build options patch:
In my case, I put the xserver sources under the tigervnc sources
(unix/xserver-XXX)
and build the X server in the cmake build directory too (seperate directories
for xserver sources/binaries).
The build system only add ../../include [include of the build directory], not
include of the xserver sources.
XSERVERLIBS_CFLAGS does not contains this include directory, therefore my build
still fails. I'm missing $(top_srcdir)/include
in the include path.
Just for the reference, my current debian/rules:
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/cmake.mk
include /usr/share/cdbs/1/rules/utils.mk
DEB_CMAKE_EXTRA_FLAGS := -DENABLE_GNUTLS=ON
XSERVER_VERSION=1.7.7
XSERVER_DIR=$(CURDIR)/unix/xorg-server-$(XSERVER_VERSION)
XSERVER_BUILD_DIR=$(DEB_BUILDDIR)/unix/xorg-server-$(XSERVER_VERSION)
extract-xserver-stamp: xserver/xorg-server_$(XSERVER_VERSION).orig.tar.gz
$(wildcard xserver/xorg-server_$(XSERVER_VERISON)-*.diff) unix/xserver17.patch
rm -rf $(XSERVER_DIR)
cd unix tar xzf ../xserver/xorg-server_$(XSERVER_VERSION).orig.tar.gz
cd $(XSERVER_DIR) patch -p1 ../../$(wildcard
xserver/xorg-server_$(XSERVER_VERSION)-*.diff)
QUILT_PATCHES=$(XSERVER_DIR)/debian/patches
QUILT_SERIES=$(XSERVER_DIR)/debian/patches/series quilt import
unix/xserver17.patch
cd $(XSERVER_DIR) QUILT_PATCHES=debian/patches
QUILT_SERIES=debian/patches/series quilt push -a
touch extract-xserver-stamp
update-xserver-stamp: extract-xserver-stamp $(wildcard unix/xserver/hw/vnc/*)
rm -rf $(XSERVER_DIR)/hw/vnc
cp -r unix/xserver/hw $(XSERVER_DIR)
touch update-xserver-stamp
configure-xserver-stamp: update-xserver-stamp
cd $(XSERVER_DIR) autoreconf -i
mkdir -p $(XSERVER_BUILD_DIR)
cd $(XSERVER_BUILD_DIR) $(XSERVER_DIR)/configure \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-static \
--without-dtrace \
--disable-werror \
--disable-debug \
--disable-unit-tests \
--with-int10=x86emu \
--with-xkb-path=/usr/share/X11/xkb \
--with-xkb-output=/var/lib/xkb \
--with-default-xkb-rules=evdev \
--disable-builddocs \
--disable-install-libxf86config \
--disable-null-root-cursor \
--enable-mitshm \
--enable-xres \
--disable-xcsecurity \
--disable-xcalibrate \
--disable-tslib \
--disable-multibuffer \
--enable-dbe \
--disable-xf86bigfont \
--enable-dpms \
--disable-config-udev --disable-config-hal \
--disable-xorg \
--disable-xquartz \
--disable-xwin \
--disable-xsdl \
--disable-xfake \
--disable-install-setuid \
--with-default-font-path=/usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,built-ins
\
--enable-aiglx \
--enable-glx-tls \
--enable-registry \
--enable-composite
[Tigervnc-devel] xserver / cmake issues
First of all, Makefile.am is missing some include path, so that a out of source tree build fails (xserver 1.7): --- tigervnc-1.0.1.svn0.orig/unix/xserver/hw/vnc/Makefile.am +++ tigervnc-1.0.1.svn0/unix/xserver/hw/vnc/Makefile.am @@ -17,7 +17,8 @@ libvnccommon_la_SOURCES = $(HDRS) vncExt libvnccommon_la_CPPFLAGS = -DVENDOR_RELEASE=$(VENDOR_RELEASE) \ -DVENDOR_STRING=\$(VENDOR_STRING)\ -I$(TIGERVNC_SRCDIR)/common -UHAVE_CONFIG_H \ - -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS) -I$(includedir)/pixman-1 -I$(includedir) + -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS) -I$(includedir)/pixman-1 -I$(includedir) \ + -I$(top_srcdir)/include bin_PROGRAMS = Xvnc @@ -49,6 +50,7 @@ libvnc_la_CPPFLAGS = $(XVNC_CPPFLAGS) -I -I$(top_srcdir)/hw/xfree86/common \ -I$(top_srcdir)/hw/xfree86/os-support \ -I$(top_srcdir)/hw/xfree86/os-support/bus \ + -I$(top_srcdir)/include \ -I$(includedir)/pixman-1 -I$(includedir) libvnc_la_LDFLAGS = -module -avoid-version My second problem is, that it seems no longer possible to build the vnc module. Linking the vnc module for the Xserver leads to an linker error, because cmake only generates non-PIC object files (eg libnetwork). autotools+libtool did this automatically. Regards, Martin Koegler -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Testing with the 1.2 Alpha version
On Tue, Jul 19, 2011 at 06:01:47PM -0400, Robert Goley wrote: The first issue is with the security types. I am specifying -SecurityTypes TLSVnc,VncAuth on the server. When I connect with all client options enabled, it uses TLSVnc. When I connect with ALL TLS options unchecked, it still connects TLSAuth. Why is that? Did I not specify the server option correctly or is the client ignoring the allowed connection methods? The same thing happens with whatever I select as the first option on the server. If I select VncAuth, it never allows using TLS even if it is the next in the list. What do you mean by TLSAuth? The VeNCrypt security type? VeNCrypt is an extended security type chooser, which supports the traditional as well es the new security types. Enabling VeNCrypt by default allows to honor the order, if new and old security types are mixed. Regards, Martin K?gler -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] New portable vncviewer
On Fri, May 13, 2011 at 05:56:53PM -0400, Brian Hinz wrote: Awesome! Thanks for making the class changes, that's been on my TODO list since we discussed this last... You should look at the character encoding handling too: InStream.readString interprets input data as ISO-8859-1. CMsgReader.readServerCutText interprets data as platform encoding (there are even JVMs out there with ASCII incompatible plattform encoding). VncAuth limit the supported password characters to ISO-8859-1 (and will probably break, if the server uses UTF-8 for password checking). CMsgWriter.writeClientCutText sends the Clipboard in plattform encoding. OutStream.writeString sends as ISO-8859-1 (converting any non ISO-8859-1 bytes to garbage). CSecurityPlain/Managed send Strings in plattform encoding. Regards, Martin K?gler -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] potential vulnerability in TLS secType?
On Thu, May 05, 2011 at 07:01:49AM -0400, Brian Hinz wrote:
Wouldn't this (also untested) work as well, and have the advantage of
relying on gnutls to verify that the handshake was completed?
diff -Nr -C 6 rfb.unix/CSecurityTLS.cxx.bak rfb.unix/CSecurityTLS.cxx
*** rfb.unix/CSecurityTLS.cxx.bak 2011-05-05 06:54:11.018963720 -0400
--- rfb.unix/CSecurityTLS.cxx 2011-05-05 06:55:24.826533250 -0400
***
*** 168,182
initGlobal();
if (!session) {
if (!is-checkNoWait(1))
return false;
- if (is-readU8() == 0)
- return true;
-
if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
throw AuthFailureException(gnutls_init failed);
if (gnutls_set_default_priority(session) != GNUTLS_E_SUCCESS)
throw AuthFailureException(gnutls_set_default_priority failed);
--- 168,179
***
*** 197,208
--- 194,208
if (err != GNUTLS_E_SUCCESS) {
vlog.error(TLS Handshake failed: %s\n, gnutls_strerror (err));
shutdown(false);
throw AuthFailureException(TLS Handshake failed);
}
+ if (is-readU8() == 0)
+ return true;
+
checkSession();
cc-setStreams(fis = new rdr::TLSInStream(is, session),
fos = new rdr::TLSOutStream(os, session));
return true;
The readU8 is a flag to signal by the server to the client, that
it can't start the handshake and therefore has to sent the error as plaintext
back
(eg because it can't read the certificate).
Your are proposing a different protocol, which don't allow to return an error
message before the handshake completed.
Regards,
Martin K?gler
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] New pre-beta build uploaded
On Fri, Mar 11, 2011 at 04:05:00PM +0100, Adam Tkac wrote: On Fri, Mar 11, 2011 at 08:41:02AM -0600, DRC wrote: Just so I fully understand the issue, what would you normally do if the WM crashes? Is there a reasonable way to recover in that case? When WM crashes then applications which are started for example from xstartup script are not terminated (so your work isn't lost). I have mainly worked with session managers like KDE (and probably also GNOME). The behaviour allows the vncserver session to be shutdown, if the user press logout. I don't remember a lost session because of this in the last years. Regards, Martin Kögler -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] New pre-beta build uploaded
On Fri, Mar 11, 2011 at 02:56:51PM -0500, Robert Goley wrote: You have been more fortunate then. My users always seem to find those unknown or unlikely crashes or closes. We have used KDE/GNOME in the past but they are kind of heavy and slow down the VNC session performance when using it over lower bandwidth connections. We use windows managers like jwm or openbox + lxpanel to provide a desktop session similar to Window's RDP sessions with all the graphical features turned off. This also allows for restricted the applications that users have access to. Keeps it simpler for them that way too. It would be interessting to compare this to behaviour of local X display managers: They must kill the X server at some point of time too, regardless if you use a failsafe session or KDE - how do they handle this decision? Regards, Martin Kögler -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Improvements for Windows installer
On Tue, Mar 08, 2011 at 08:33:20PM -0600, DRC wrote: Windows is still suffering from the TLS refresh issue described earlier. It affects VirtualGL as well (you have to move the mouse to see the 3D application change frames.) I don't have the time to look into this at the moment, but IMHO, it should be fixed before we release 1.1 beta. Changing the priority of events (I could sent it as patch, if requested) should improve this issue. To get the full frame rate on the user display, you probably have to investigate, how often to force a window update and need something like tcbench for windows to verify the result. Or should we ignore the problem, as we get a new common viewer? Regards, Martin Kögler -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Security types on server
On Tue, Mar 01, 2011 at 08:53:27PM -0600, DRC wrote: Is there a good reason why only VncAuth and TLSVnc are enabled on the server by default? Would it be reasonable to enable the other secure types as well? X509* make no sense without specifing certificates. *None and Plain should not be enable by default because of security issues. *Plain require some additional configuration, as most users probably only want to authentificate as themself. Regards, Martin Kögler -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
On Fri, Feb 25, 2011 at 07:06:39PM -0500, Robert Goley wrote:
Here are the results from using the different encodings:
OpenBox Window Manager:
ZLRE: 11428 kbs (Server has a little load at the moment,
this was around 2 when tested earlier...)Has freezing issue
in TLS
Tight: 19000kbps or greater.Has freezing issue in TLS
Hextile:2 kbps.Has freezing issue in TLS
Raw:2 kbps.Has freezing issue in TLS
For reference, I am getting the same results using the Motif Window
Manager (MWM). I used it for testing because they really don't come
much simpler other than TWM...
As far as I can tell, it looks like a problem in the Windows vncviewer:
The windows viewer keeps updating its internal frame buffer and call
invalidate_modifed regions of the window with InvalidateRect
(win/vncviewer/DesktopWindow.cxx DesktopWindow::updateWindow).
With InvalidateRect windows is free to send the WM_PAINT message, when
it thinks, that the application has time for it. When this WM_PAINT
messages is delivered by windows, the content of the windows is
updated.
For the viewer, all server messages have the highest priority,
followed by the various windows messages. The least priority has
WM_PAINT.
The problem is, that the viewer is (for windows) too busy for
delivering the WM_PAINT. TLS seems to be a reliable trigger, but it
should be possible to construct work loads for the non-TLS case too,
where the screen updates are stalled.
How can it be fixed:
1) The situation can be improved, if in win/vncviewer/CConn.cxx the priority of
the Windows events is raised:
In CConn::blockCallback():
// Wait for socket data, or a message to process
DWORD result = MsgWaitForMultipleObjects(1, sockEvent.h, FALSE, INFINITE,
QS_ALLINPUT);
if (result == WAIT_OBJECT_0) {
// - Network event notification. Return control to I/O routine.
break;
} else if (result == WAIT_FAILED) {
// - The wait operation failed - raise an exception
throw rdr::SystemException(blockCallback wait error, GetLastError());
}
// - There should be a message in the message queue
MSG msg;
while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) {
// IMPORTANT: We mustn't call TranslateMessage() here, because instead we
// call ToAscii() in CKeyboard::keyEvent(). ToAscii() stores dead key
// state from one call to the next, which would be messed up by calls to
// TranslateMessage() (actually it looks like TranslateMessage() calls
// ToAscii() internally).
DispatchMessage(msg);
}
=
// Wait for socket data, or a message to process
DWORD result = MsgWaitForMultipleObjects(1, sockEvent.h, FALSE, INFINITE,
QS_ALLINPUT);
if (result == WAIT_FAILED) {
// - The wait operation failed - raise an exception
throw rdr::SystemException(blockCallback wait error, GetLastError());
}
MSG msg;
while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) {
// IMPORTANT: We mustn't call TranslateMessage() here, because instead we
// call ToAscii() in CKeyboard::keyEvent(). ToAscii() stores dead key
// state from one call to the next, which would be messed up by calls to
// TranslateMessage() (actually it looks like TranslateMessage() calls
// ToAscii() internally).
DispatchMessage(msg);
}
if (result == WAIT_OBJECT_0) {
// - Network event notification. Return control to I/O routine.
break;
}
2) Add regular explicit calls to UpdateWindow(hWnd) to force an immediate
update.
Maybe in DesktopWindow::processMessage, case WM_TIMER after the call
to updateWindow().
Regards,
Martin Kögler
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Peculiar Refresh Issue with TLS
On Fri, Feb 25, 2011 at 03:35:39PM -0600, DRC wrote: Are you using a compositing window manager by chance? I noticed a similar issue with my installation of Gnome, and I think it was related to me having tried to get it working with compiz earlier. I didn't have time to look into it, so I just punted and switched to KDE for now. :) Don't know why it would only be happening with TLS, though. It may not even be the same issue as what I was seeing. On 2/25/11 2:29 PM, Robert Goley wrote: I have been doing more testing with the binaries DRC provided. Thanks for those btw. For the most part, these are working great. I have noticed that most of the time when I use them and connect using TLSPlain or TLSVnc that I get freezes in the screen refreshes. For example, when running a program that I know is constantly updating the screen, the screen will only update when I move the mouse. I am not talking about small delays either. It will not update the screen for minutes then I move the mouse and the entire screen updates for me to see the command has entirely completed. Think of creating a tarball of a larger directory where the command with take a couple of minutes, run the command and then do not move the mouse for several minutes then moving it to see the command completed. It is really annoying for little things like that. It does not happen when running in Plain or VncAuth modes, just in TLS ones. I am connecting over a gigabit ethernet where client and server both support gigabit connections.When connecting using TLS, it uses the Tight extension and gets a line speed of 2 kbps. It shows those same rates for non TLS connections. It is kind of funny to watch because the screen will update fine as long as I move the mouse. It freezes instantly when the mouse stops too. Anyone got any ideas on this? It did not seem to do this prior to all the performance improvement patches for GL but I am not sure if this would be related. What client/server combination are you using? I can repoduce this (KDE desktop on server, win client, TLS) - but only using the tight encoding. ZRLE with TLS is fine. I can't reproduce it with KDE desktop to linux client. I'll try to further analyse the problem. Regards, Martin Kögler -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Sat, Feb 19, 2011 at 04:17:14PM -0600, DRC wrote: On 2/18/11 4:55 AM, Adam Tkac wrote: Definite improvement. Here's what I now see with VirtualGL: Machine 1: Pentium 4 Xeon 2.8 GHz single core Machine 2: AMD X2 5050e 2.6 GHz dual core 1--2 - ServerClient fps CPU Time/ CPU Time/ (1240x900)Frame (ms)Frame (ms) 64-bit, no TLS 19.05 33.87 14.54 64-bit, TLS 12.00 (-37%) 62.11 (+83%) 20.59 (+42%) 32-bit, no TLS 16.54 37.67 16.87 32-bit, TLS 10.45 (-37%) 68.84 (+83%) 24.51 (+45%) 2--1 - Server Client fpsCPU Time/ CPU Time/ (1240x900) Frame (ms) Frame (ms) -- 64-bit, no TLS 22.86 29.70 18.29 64-bit, TLS 18.78 (-18%) 32.44 (+9.2%) 34.35 (+88%) 32-bit, no TLS 17.48 36.39 20.94 32-bit, TLS 16.04 (-8.2%) 38.65 (+6.2%) 38.97 (+86%) Adding SSH Tunnling to the comparison would be interesting (the CPU time of ssh must be added to the server/client time, as the SSH process does the crypto operations on behalf of TigerVNC). Very interesting that the Intel machine takes a much larger relative hit than the AMD machine. Hasn't the pentium 4 suffered from log pipelines (high clock frequency, but fewer operation per clock cycle)? libgcrypt only ships optimized assembler code (also using the various vector extensions) for asymetric cipher like RSA. libgcrypt is mostly classic C code (including the symetric ciphers), so it takes advantage of fast integer units. I did some profiling: With TLS, the vncviewer hot spots are: * ~23% in libgcrypt * ~14% in the jpeg code * ~14% again in the jpeg code With TLS, the Xvnc hot spots are: * 17.4% in zlib * 14.3% libcrypt * 13% rfb::ComparingUpdateTracker::compareRect * 12% in the jpeg code For zlib, I need to check, what portion is triggered by gnutls. I also need to find out, what the libgcrypt hotspot is - I assume, it's AES/DES or a similar symetric cipher. If somebody wants to improve the overall performance of Xvnc, ComparingUpdateTracker::compareRect could be of interest. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Thu, Feb 17, 2011 at 09:06:33AM +0100, Martin Koegler wrote: On Wed, Feb 16, 2011 at 03:21:38AM -0600, DRC wrote: However, I did discover that playing the 1920x1080 version of Big Buck Bunny from the beginning using VLC in full-screen mode makes a good 2D benchmark. The beginning of this movie has full-scene motion on almost every frame, so if you start TCBench very soon after starting the movie, you should get a good reading. When I do this, I get 14-15 fps with TLS disabled and 4.5 fps with TLS enabled. In other words, about the same relative difference as I got with GLXspheres and VirtualGL. You should be able to perform the above test using my TigerVNC binaries, which will confirm whether the problem is specific to my build or not. I can reproduce similar frame rates with my versions. I'll look, what is happening. The attached patch improves frame rates to 9-11 fps. Regards, Martin Kögler From c1d7027e607316edad810b0c4b5e43d5adc91142 Mon Sep 17 00:00:00 2001 From: Martin Koegler mkoeg...@auto.tuwien.ac.at Date: Fri, 18 Feb 2011 07:05:13 +0100 Subject: [PATCH] Disable Debug Logging Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at --- common/rfb/CSecurityTLS.cxx |2 +- common/rfb/SSecurityTLS.cxx |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common/rfb/CSecurityTLS.cxx b/common/rfb/CSecurityTLS.cxx index c774c3d..fdc00c5 100644 --- a/common/rfb/CSecurityTLS.cxx +++ b/common/rfb/CSecurityTLS.cxx @@ -62,7 +62,7 @@ #define WITHOUT_X509_TIMES #endif -#define TLS_DEBUG +//#define TLS_DEBUG using namespace rfb; diff --git a/common/rfb/SSecurityTLS.cxx b/common/rfb/SSecurityTLS.cxx index e6202a8..fd7b003 100644 --- a/common/rfb/SSecurityTLS.cxx +++ b/common/rfb/SSecurityTLS.cxx @@ -35,7 +35,7 @@ #include rdr/TLSOutStream.h #define DH_BITS 1024 /* XXX This should be configurable! */ -#define TLS_DEBUG +//#define TLS_DEBUG using namespace rfb; -- 1.7.2.3 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Wed, Feb 16, 2011 at 03:21:38AM -0600, DRC wrote: However, I did discover that playing the 1920x1080 version of Big Buck Bunny from the beginning using VLC in full-screen mode makes a good 2D benchmark. The beginning of this movie has full-scene motion on almost every frame, so if you start TCBench very soon after starting the movie, you should get a good reading. When I do this, I get 14-15 fps with TLS disabled and 4.5 fps with TLS enabled. In other words, about the same relative difference as I got with GLXspheres and VirtualGL. You should be able to perform the above test using my TigerVNC binaries, which will confirm whether the problem is specific to my build or not. I can reproduce similar frame rates with my versions. I'll look, what is happening. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Patch to integrate libssh
On Tue, Feb 15, 2011 at 04:42:32PM -0600, DRC wrote: On 2/15/11 3:11 PM, Martin Koegler wrote: Making the vncviewer ssh into the server as the user, detecting all running VNC servers of the user and finally let the user select to connect to one instance or start a new session: I'm really missing such a feature [I had done such experiments too: http://e9925248.users.sourceforge.net/vnctermserv/]. The challenge for such script solution is, that they are complicated on the windows client side [no scripting, no ssh]. That's why a lot of people are implementing it via a web portal. You log into the portal, and it will invoke and parse 'vncserver -list' to show you your active sessions, letting you either connect to one of those or start a new one. In either case, a new one-time password is generated, and a .vnc connection file is generated on the fly with this password, the hostname, port, etc. Then, you simply open the .vnc file with your installed version of VNCViewer. I modified the TurboVNC Unix viewer to read these connection files as well, and it would be easy to make TigerVNC do the same thing. Both approches use different security models: * sshing as user on the server and then executing the rest (session listing, ...) as user too fits in the unix permission schema: The client only does automatically, what the user could have done manually - so no extra permissions are necessary. * In the web portal case, the webserver needs additional privileges to act on behalf of the user (eg. list/start sessions). And: If there is an need for an additional web application based on the same technology as the VNC portal, how many user are deploying it on the same webserver, so that that the second application runs with the additional permissions too? Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Patch to integrate libssh
On Tue, Feb 15, 2011 at 08:22:15AM -0700, Mike Fisk wrote: 1. Complete session management functionality including flexible authentication, strong encryption, spawning new sessions, reconnecting to existing sessions, etc. I lump a lot of things together that do not have to be part of the RFB protocol and X server process. As for #1, I use a client-side script and server-side script where the convention is that the client SSHs to the server (and can therefore use whatever authentication and/or encryption is allowed negotiated there) and the script then provides an RFB connection over stdin/stdout. It's a Unixy (or plan 9ish) approach and doesn't require the existence or use of a VNC password (which is a non-starter in this sort of environment --- especially when you don't allow reusable passwords in the first place). My only feature request to make this cleaner would be for the VNC server to support vncconnect to a Unix domain socket rather than an INET socket. The client-side script builds a local socket that connects to this ssh stdio and tells a client (vncviewer, Chicken of the VNC on Mac) to connect to it. It passes the current (or requested) screen resolution as an argument tot he server script. Again, this would be cleaner if there was something like SSH's ProxyCommand that specified a command that the viewer would use to create to connect to the server instead of an INET socket. I don't use VIA at all in this scheme. Making the vncviewer ssh into the server as the user, detecting all running VNC servers of the user and finally let the user select to connect to one instance or start a new session: I'm really missing such a feature [I had done such experiments too: http://e9925248.users.sourceforge.net/vnctermserv/]. The challenge for such script solution is, that they are complicated on the windows client side [no scripting, no ssh]. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Sun, Feb 13, 2011 at 04:32:46PM -0600, DRC wrote: So what exactly is a default Linux installation? I don't think anyone can reasonably conclude that what is true for their Linux installation is true for all Linux installations. The performance problems are triggered by running running high performance applications like virtualgl, which is not part of any major distribution]. So any user of default installation of a major linux distribution has either an Xvnc without 3D support or is limited by the software renderer - they will not hit your test case. I still don't fully buy that OpenGL isn't causing some amount of CPU overhead that may still be limiting the frame rate, but I agree that a 2D frame flipping benchmark would be a better test. The overhead is the same for None or TLSNone, as OpenGL is drawing into the frame buffer - TLS only affects the data transfer between Xvnc and vncviewer. In the meantime, let's make the assumption that neither one of us is mistaken and that there really is a difference in how our systems are performing with GnuTLS. The only explanation I can come up with for that is that our versions of GnuTLS were built differently. Perhaps there is some performance feature that is enabled in yours but not mine? I've tried building against the GnuTLS chain that is on RHEL 4, as well as downloading the latest greatest (GnuTLS 2.10.4) chain and building it from source, and I get identical results. I'm only using the precompiled libraries from my Debian distribution. They all should have been upgraded to Squeeze, but I can't guarantee, that there is something left from an older releases. When you are running your tests, are you using the binaries I built and uploaded, or are you using your binaries, which are presumably built against the system installation of GnuTLS? If you haven't tried my binaries, please try them. That will tell us whether the above hypothesis is correct. I have downloaded your 64 bit binaries, but can not test, as Xvnc does not support the GLX extension [(EE) AIGLX error: dlopen of /tmp/tigerbuild.c27921/tigervnc-1.0.90/linux64/xorg.build/lib/dri/swrast_dri.so failed]. Also, I was using TLSVnc, not TLSNone, but that shouldn't make a difference, right? Yes, this should not make any difference - TLSVnc only adds the password exchange, but after that, the protocol is the same. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Sat, Feb 12, 2011 at 03:19:48PM -0600, DRC wrote: You have to run glxspheres with vglrun. Otherwise, it will use the software OpenGL renderer in TigerVNC, and that will be the bottleneck, not TigerVNC's image pipeline. Also realize that the methodology is not just running GLXspheres and reading the output of that benchmark. You have to run vglrun -sp glxspheres -fs to ensure that frame spoiling is disabled in VirtualGL, so that VGL is drawing only the frames that get rendered. You then have to measure the frame rate from the client using TCBench, to ensure that you are reading only the frames that get delivered to the client. Using TCBench may not make any difference on a fast network, because generally TigerVNC won't drop frames in that scenario, but it definitely can drop frames in a low-bandwidth environment, so the frame rate reported by GLXspheres wouldn't be accurate in that case. Also, if you want to reproduce the exact scenario under which I am running the benchmarks, set your TigerVNC geometry to 1240x900 and use a 1280x1024 resolution on the client display. I have captured the frame rates using tcbench: * Xvnc arguments: -SecurityTypes TLSNone,None -geometry 1280x900 -depth 24 * glxspheres -fs * all runinng on one computer * vncviewer with None Samples: 1493 Frames: 250 Time: 30.007244 s Frames/sec: 8.331322 Samples: 1493 Frames: 249 Time: 30.000328 s Frames/sec: 8.299909 * vncviewer with TLSNone Samples: 1493 Frames: 208 Time: 30.003126 s Frames/sec: 6.932611 Samples: 1493 Frames: 209 Time: 30.014431 s Frames/sec: 6.963317 6.93/8.3 = ~16 % less frame rate As the limit is the software renderer, I wanted to try a simpler GL application: I have modifed glxgears to be full screen [unsigned int winWidth = 1280, winHeight = 900;] - every thing else is the same. * vncviewer with TLSNone Samples: 1491 Frames: 651 Time: 30.017669 s Frames/sec: 21.687227 Samples: 1492 Frames: 657 Time: 30.013056 s Frames/sec: 21.890473 * vncviewer with None Samples: 1493 Frames: 707 Time: 30.014369 s Frames/sec: 23.555384 Samples: 1493 Frames: 714 Time: 30.014356 s Frames/sec: 23.788616 21.6/23.7 = ~9% less frame rate vglrun (VirtualGL-2.2.tar.gz, 7ab7a3ff9c6e36879a1e37e2cacc7f18) is not working on my Debian stable system: Polygons in scene: 62464 [VGL] Shared memory segment ID for vglconfig: 950273 [VGL] XOpenDisplay (name=NULL [VGL] Opening local display :0 [VGL] XQueryExtension (dpy=0x01efd120(:0.0) name=XKEYBOARD *major_opcode=144 *first_event=97 *first_error=153 ) 0.020981 ms dpy=0x01efd120(:0.0) ) 0.865936 ms [VGL] glXChooseVisual (dpy=0x01efd120(:0.0) screen=0 attrib_list=[0x0004 0x0008=0x0008 0x0009=0x0008 0x000a=0x0008 0x000c=0x0001 0x0005 ] [VGL] WARNING: VirtualGL attempted and failed to obtain a Pbuffer-enabled [VGL]24-bit visual on the 3D X server :0. If the application [VGL]subsequently fails, then make sure that the 3D X server is configured [VGL]for 24-bit color and has accelerated 3D drivers installed. ERROR (559): Could not obtain RGB visual with requested properties Xserver has 24bit support: screen #0: dimensions:1920x1080 pixels (508x285 millimeters) resolution:96x96 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x10c depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xd2001d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask StructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals:64 default visual id: 0x21 3D is also working: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 [...] client glx vendor string: Mesa Project and SGI client glx version string: 1.4 [...] OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RS780 9614) 20090101 TCL DRI2 OpenGL version string: 1.5 Mesa 7.7.1 And: :0 is definitly my xorg server. So sorry, I wast not able to test with your method. The best test for the performance regression would be a simple X program, which switches very fast between a few, very different, full screen images and does not require very much cpu resources (in the program and Xvnc). = So TLS encryption is using more resources and is slower than not encrypting - but for default linux installations, the slowdown is less than 25 %. The amount of data transfered over the network increases too - if the bandwith is already saturated, it can get worse. Regards, Martin Kögler -- The ultimate
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Fri, Feb 11, 2011 at 10:53:48AM -0600, DRC wrote: I would still be interested in knowing whether it would be feasible to use the auth extensions without GnuTLS. The main question is: How much more fragementation should be added to the VNC world? qemu has eg. implemented VeNCrypt: http://git.qemu.org/qemu.git/tree/ui/vnc-tls.c The various VNC variants were (are?) not good at cooperating: they only share a small basic profile (from 3.3 version), but any newer features are only supported in a small number of (or even only one) variant. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Thu, Feb 10, 2011 at 04:40:13AM -0600, DRC wrote: On 2/10/11 2:24 AM, Martin Koegler wrote: I really wonder how useful of a feature built-in session encryption is if it's this slow. Without encryption, I can get approximately 20 Megapixels/second. Tunneling through SSh, about the same. With TLSVnc, I get about 7.5 Megapixels/second. For my purposes, that's completely useless. Using TLSNone, I still get 20MBit in a local LAN. In my option, tight encoding is worse (eg. skipping frams on the KDE splash screen) on animations than eg. ZRLE. What do you mean still get 20 Mbit? You mean Megapixels/second? Or do you mean Megabits/second of throughput? Because without VeNCrypt, my I mean the value showen in the viewer info dialog. What tools are you using? throughput is more like 50 Mbits/sec. It's 2.5x faster, roughly, with SSh (or no encryption) than with GnuTLS. I'm not the only one who has observed that GnuTLS is slow. Google 'gnutls openssl performance' and you'll see that others have observed a similar disparity. My workload is VirtualGL (remote 3D), and with 3D, it's pretty critical to maintain 15 frames/second or higher to ensure that the application feels interactive. Screen sizes of 2 Megapixels are becoming fairly common, so ideally what I want is 30+ Megapixels/second. I can get 35-40 with TurboVNC on modern hardware. With TigerVNC, I can nominally get about 30% less than that with encryption disabled, which is still quite usable. With VeNCrypt, however, it drops down to 7.5 Megapixels/second, which is too slow to be useful for doing any real work with 3D applications. I've been in the remote display business for well over a decade now, and I can tell you from experience that people just don't read documentation when they download software. They just download it, install it, and if it doesn't perform as they expect, they throw it out and never try it again. If TigerVNC is being billed as a high-performance version of VNC, then it needs to be performant by default. If it's being billed as a secure version of VNC, then it needs to be secure by default. Those two goals may not be mutually achievable. I'm using Tigervnc (and had developeed it) for accessing normal desktop in a secure way on Windows/Linux. In my option, VenCrypt encryption works for this use case. Video / 3D are a different use case, which requires optimisations (eg. there is even an optimized version of libjpeg). gnutls is used with its default settings and I have not looked, how TLSOutput stream blocks the data into packets and when the data is flushed to the network. For your usecase, such analysis are probably necessary. I am not comfortable shipping binaries with GnuTLS support if the out-of-box default behavior is 38% as fast as 1.0.1. I strongly believe that the server needs to re-order the default security types to be VncAuth, VeNCrypt, TLSVnc. In other words, the default out-of-box behavior would be the same as 1.0.1-- to use VncAuth if both ends support it. If someone is paranoid and wanted to use the much slower-but-more-secure VeNCrypt functionality as a default, they would need to specify -SecurityTypes when starting vncserver. Ideally, in the long term, this would be restricted by means of an authentication configuration file that the SysAdmin could use to force the use of only certain security types. VeNCrypt should be the first, so that tigervnc honors the security type order. That seems like a circular argument. Please justify. See my other mail: VeNCrypt is a chooser and if it is not on the first position, a effective order is different. The client should have all security types enabled by default (as currently). I have no objections to modifying the list of default security types in the server. If we leave things the way they are, users will think that our software has slowed down by more than 2X since 1.0.1. Further, these security types need to be documented. They are not mentioned in our man pages, and it is incredibly non-obvious what they do. Also, how does one enable user/password authentication? I see that in the options dialog, but it doesn't appear to correspond to a command line option. -SecurityTypes VeNCrypt,XXXPlain -PlainUsers OK, I got that working, now how do I get it working without session encryption? Plain is also available without any encryption, but not enabled by default. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing
Re: [Tigervnc-devel] The 1_1 branch and 1.1 beta release
On Thu, Feb 10, 2011 at 04:18:52PM -0600, DRC wrote: On 2/10/11 4:00 PM, Martin Koegler wrote: Please don't mix up Encryption with VeNCrypt. VeNCrypt consists of two parts: 1) An extended chooser, which has enough available security type numbers even for every hobby developer. 2) New security types (TLS encryption with/without certificates, Username/Password authentification + various combinations also reusing the classic security types). OK, but am I correct in asserting that, in TigerVNC, as it's currently implemented, there is no way to build VeNCrypt without encryption? For now, I just want encryption to be disabled by default, because it's so slow. Longer term, it would be nice to have the ability to build TigerVNC with only the authentication extensions and not require GnuTLS to do so. It should be possible (HAVE_GNUTLS not defined). In that case, VeNCrypt + Plain are still available. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] The 1_1 branch and 1.1 beta release
On Fri, Feb 11, 2011 at 12:09:17PM -0600, DRC wrote: On 2/11/11 2:24 AM, Martin Koegler wrote: It should be possible (HAVE_GNUTLS not defined). In that case, VeNCrypt + Plain are still available. Right you are. I built without GnuTLS, and Plain definitely does still work. That makes me feel better about the feature, in general. I guess the two outstanding issues, then, are: -- Should we make VeNCrypt an implicit security type, rather than explicit (I say yes.) If you need a patch: http://e9925248.users.sourceforge.net/tigervnc/tigervnc_1.0.0.svn0-1.debian.tar.gz See debian/patches Patch 0002. It changes the security type defaults too - you probably want to skip this for the official version. Instead drop all occurences of VeNCrypt in the defaults. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Integration work completed
On Thu, Feb 10, 2011 at 09:45:22PM -0600, DRC wrote: In the course of this work, I've discovered much about how to build GnuTLS (and how not to.) I'm not sure how people are currently using that technology on Windows, but there doesn't seem to be a sane way to build static libraries for GnuTLS using Visual C++. Since shipping a binary that depends on the GnuTLS DLLs is equally problematic, what I did for now was to generate three different builds -- one using 32-bit MinGW that includes VeNCrypt support (but no WinVNC), as well as 32-bit and 64-bit builds using Visual C++, both of which include WinVNC (but no VeNCrypt.) At some point in the future, I hope that someone figures out a way to build the GnuTLS libraries using Visual C++. For the VeNCrypt project, I have been building GNU TLS with MS VC 6.0 (as part of the project like zlib). I thought, that the project would prefer out of tree GNU TLS, but: If somebody with commit access, would commit (a not too broken) solution for adding GNU TLS to the TigerVNC sources, I'll start working on this. On a related note, Adam, do we still need to support autotools on Windows? We will still need to keep some of the Makefile.am files around, because they specify EXTRA_DIST, but we should remove the actual Windows automake code if it isn't needed anymore. CMake works fine with GnuTLS, as far as I can tell. They are useful for cross-compiling (mingw as cross-compiler) - in fact, they were the only way for me to get an working windows viewer with GNU TLS support. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Patch to integrate libssh
On Fri, Feb 11, 2011 at 02:22:04PM -0600, DRC wrote: Well, yes and no. libssh requires OpenSSL, right? That means we have to statically link with OpenSSL in order to produce cross-compatible binaries. Static linking with OpenSSL is, I can tell you from experience, not my favorite pastime. And now, if someone wants to build a full-featured version of TigerVNC, they need OpenSSL, libssh, GnuTLS, libgcrypt, libgpg-error, libtasn1. Yuck. I really want us to reduce some of the existing complexity before we start adding more. Isn't OpenSSL released under a GPL incompatible license? Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Wed, Feb 09, 2011 at 10:09:25PM -0600, DRC wrote: An unrelated issue is that whenever I try to use the vncviewer GUI to set the Zlib level to something other than the default, the server crashes (the log says ZlibOutStream: deflate failed.) In my self compiled windows viewer, I can change it without crashing my Xvnc - I can only reproduce it using the unix viewer (My debian Xvnc is not affected, but the Xvnc versions I compiled for a different distribution). Ugh. OK, so this was due to VeNCrypt. It is apparently enabled by default if both server and viewer support it. I do not like that at all. It's particularly problematic because, once enabled, there is no way to subsequently disable it without disconnecting and reconnecting (the VeNCrypt boxes in the options dialog are all grayed out once the connection has been established.) I really wonder how useful of a feature built-in session encryption is if it's this slow. Without encryption, I can get approximately 20 Megapixels/second. Tunneling through SSh, about the same. With TLSVnc, I get about 7.5 Megapixels/second. For my purposes, that's completely useless. Using TLSNone, I still get 20MBit in a local LAN. In my option, tight encoding is worse (eg. skipping frams on the KDE splash screen) on animations than eg. ZRLE. I am not comfortable shipping binaries with GnuTLS support if the out-of-box default behavior is 38% as fast as 1.0.1. I strongly believe that the server needs to re-order the default security types to be VncAuth, VeNCrypt, TLSVnc. In other words, the default out-of-box behavior would be the same as 1.0.1-- to use VncAuth if both ends support it. If someone is paranoid and wanted to use the much slower-but-more-secure VeNCrypt functionality as a default, they would need to specify -SecurityTypes when starting vncserver. Ideally, in the long term, this would be restricted by means of an authentication configuration file that the SysAdmin could use to force the use of only certain security types. VeNCrypt should be the first, so that tigervnc honors the security type order. If we leave things the way they are, users will think that our software has slowed down by more than 2X since 1.0.1. Further, these security types need to be documented. They are not mentioned in our man pages, and it is incredibly non-obvious what they do. Also, how does one enable user/password authentication? I see that in the options dialog, but it doesn't appear to correspond to a command line option. -SecurityTypes VeNCrypt,XXXPlain -PlainUsers Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] The 1_1 branch and 1.1 beta release
On Thu, Feb 10, 2011 at 10:27:33AM +0100, Pierre Ossman wrote: On Wed, 09 Feb 2011 03:15:14 -0600 DRC dcomman...@users.sourceforge.net wrote: I could write a book on the difficulties I've had with GnuTLS. I am ultimately finding that I have to pretty much build it from source on all of the platforms. Honestly, I don't really care about the encryption aspects of it at all, but the authentication extensions are important, because those will eventually be my only vehicle to replace the existing user/password PAM authentication feature in TurboVNC. Thus, I'm kind of left in an awkward position, since I'm the only one of the three major players who has to support both GnuTLS and stable platforms like RHEL 4 and 5. We could always port over an authentication method that supports username/password without the full encryption framework. I don't have any objections to that. It's already present in the SVN version, but not enabled in the default security type list: Plain sends a user + password string to the server. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] The 1_1 branch and 1.1 beta release
On Thu, Feb 10, 2011 at 04:01:26AM -0600, DRC wrote: We had one-- the Tight Security Extension. :) I signed off on removing it before I fully understood the ramifications. Please don't mix up Encryption with VeNCrypt. VeNCrypt consists of two parts: 1) An extended chooser, which has enough available security type numbers even for every hobby developer. 2) New security types (TLS encryption with/without certificates, Username/Password authentification + various combinations also reusing the classic security types). The Tight security extension was a different chooser implementation (so was something similar to 1): It included a (never implemented) tunnel type [=encryption] and an authentification type. So the main difference is, that with VeNCrypt you can say that the server allows (TLS with VNCAuth) or (X509 with None), while tight allowed only (TLS or X509) and (VNCAuth or None). Any security type (encryption or authentification) can be hooked into VeNCrypt as it could be hooked into the Tight Security Type. Side node: In my option, it would be the best, to let the VeNCrypt security type vanish for our users (by putting it automatically as first element to the list of enabled security types) - so enabling it by default as done for the tight security type. This still works, even if the user only enables VNCAuth/None and/or communicates with a non-VenCrypt capable VNC implementation. A user is more likely to think, that he wants eg. X509Plain as first, VncAuth as second and TLSNone as third alternative. Currently, he has to add VeNCrypt manually. If he does not add it as first element, the effective order is different: * First come all standard security types from the list up to the position of VeNcrypt. * After that the whole list is appended. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] The 1_1 branch and 1.1 beta release
On Thu, Feb 10, 2011 at 03:46:17PM -0600, DRC wrote: On 2/10/11 3:35 PM, Martin Koegler wrote: We could always port over an authentication method that supports username/password without the full encryption framework. I don't have any objections to that. It's already present in the SVN version, but not enabled in the default security type list: Plain sends a user + password string to the server. That worked. Thanks! I'll say again that all of this really needs to be documented (but I'm not volunteering.) We have: * VeNcrypt - in my option this should be always at position 1 (see my other mail for reasons) * None - no encryption/no authentification * VNCAuth - no encrpytion/VNC Authentification * Plain - no encryption/send user+password * TLSNone - anonymous TLS encryption / no authentification * X509None - X509 based encryption / no authentification * TLSVnc = TLSNone + VNCAuth * X509Vnc = X509None + VNCAuth * TLSPlain = TLSNone + Plain * X509Plain = X509None + Plain Options at the server: * VNCAuth has an password file option [eg. PasswordFile] * Plain has a user list option (PlainUsers) * X509None (+combinations) need x509cert and x509key All other security types have no options. Options at the client: * X509None (+combinations): x509ca + x509crl * VNCAuth: passing the password via a file is possible All other security types have no options. Regards, Martin Kögler -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Compiling under Windows using CMake
There has been checked in some GNUTLS support for cmake recently, so I wanted to try it: Installing VC Express, the newst binary of CMake and GNUTLS for Windows was easy. Calling cmake on a clean tigervnc checkout yields to an (warning?) message, while determining the build date [Only on the first run or after cleaning the cache]. After that, CMake failed, because it could not determine GNUTLS_INCLUDE_DIR and GNUTLS_LIBRARY. The GUI only offered the options to run configure again or to clean the cache. Setting CMAKE_PREFIX_PATH to the GNUTLS install directory allowed me to get rid of the GNUTLS_INCLUDE_DIR message. GNUTLS_LIBRARY was still missing, so it does not allowed to generate any makefiles. I solved the problem by using the cygwin mingw compiler and the autotools build system. Side note: Are the zoom buttons in the windows viewer working for anybody? My 24 bit depth KDE 4 desktop looks like modern art, if any kind of zoom is in use. Regards, Martin Kögler -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Exporting only one window via TigerVNC
On Sat, Dec 18, 2010 at 06:47:08PM +0100, Gabriele Tedeschi wrote: is it possible to export only one window via TigerVNC server, running on Windows 7 64 bit ? As far as I know, vnc only exports the whole desktop. Regards, Martin Kögler -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH 00/10] VeNCrypt java support
On Thu, Nov 11, 2010 at 03:42:39PM +0100, Adam Tkac wrote: 6. Implment TLS security type 7. Implement X509 Security types Just a design question. Wouldn't be better to merge TLSTunnel, TLSTunnelBase and X509Tunnel classes to the one class as I did it in common/rfb/CSecurityTLS.*? In my opinion X509 and TLS classes contain nearly same code so it will be nice to have it in the one class (and constructor will take boolean parameter which will select between anonymous/X.509 TLS). I had these classes sitting in one of my development trees for some time, so I just was lazy and copied them 1:1. Feel free to merge them, if you think its better - I can live with both solutions. Personally, I would probably still prefere the split classes. In the java case, a useful X509 is probably bigger (1:2 - all certificate checking is still missing). 8. Disable TightVNC security type I will disable TightVNC type in the Java client later. 9. Remove TightVNC security type from server 10. Remove Tightvnc Security type from java client Not sure about those two patches, yet. I still think, its the best to let the tightvnc security type die. It provides no benefit for tigervnc and is little used (and therefore tested) code. The other option would require: * add VeNCrypt as tightvnc authentification type and * add support for tightvnc authentification to the C client Regards, Martin Kögler -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Dialogs for certificates (Unix client only)
Two general comments:
* This patch will probably break the windows build, as it adds an
msg!=NULL assert without setting the variable on Windows. The best
solution would be to add the windows implementation too.
* CSecurityTLS is only available, if tigervnc is built with GNUTLS.
So it should break any non-GNUTLS build. I would msg to CSecurity to
avoid many ifdefs.
In the following, I'll assume, that msg has been move to CSecurity:
Index: unix/vncviewer/CConn.cxx
===
--- unix/vncviewer/CConn.cxx (revision 4194)
+++ unix/vncviewer/CConn.cxx (working copy)
@@ -21,6 +21,9 @@
//
#include unistd.h
+#include errno.h
+#include sys/stat.h
+#include sys/types.h
I can't spot any change in this file, requiring this.
Index: unix/vncviewer/vncviewer.cxx
===
--- unix/vncviewer/vncviewer.cxx (revision 4194)
+++ unix/vncviewer/vncviewer.cxx (working copy)
@@ -33,6 +33,7 @@
#include locale.h
#include os/os.h
#include rfb/Logger_stdio.h
+#include rfb/CSecurityTLS.h
#include rfb/LogWriter.h
#include network/TcpSocket.h
#include TXWindow.h
@@ -278,6 +279,8 @@
Copyright (C) 2004-2009 Peter Astrand for
Cendio AB\n
See http://www.tigervnc.org for information
on TigerVNC.);
+ rfb::CSecurityTLS::setDefaults();
+
// Write about text to console, still using normal locale codeset
snprintf(aboutText, sizeof(aboutText),
gettext(englishAbout), PACKAGE_VERSION, buildtime);
This will break non-GNUTLS builds.
Just an idea:
As the whole thing (with ifdefs) is needed on unix/windows server, why
not add a SecurityClient::setDefaults:
void SecurityClient::setDefaults()
{
#ifdef HAVE_GNUTLS
CSecurityTLS::setDefaults();
#endif
}
So only SecurityClient/Server needs to know, if TLS is supported.
Index: common/rfb/CSecurityTLS.cxx
===
--- common/rfb/CSecurityTLS.cxx (revision 4194)
+++ common/rfb/CSecurityTLS.cxx (working copy)
@@ -76,6 +82,24 @@
crlfile = x509crl.getData();
}
+void CSecurityTLS::setDefaults()
+{
+ char* homeDir = NULL;
+
+ if (strlen(x509ca.getData()) == 0) {
Why didn't you just unconditionally change the default value, regardless of the
user setting?
This way, the default value should be consitent.
+if (gethomedir(homeDir) == -1)
+ vlog.error(Could not obtain home directory path, failed to open
~/.vnc/x509_certs);
Wouldn't be the first part of the error message more meaningful:
+ vlog.error(Could not obtain home directory path);
+else {
+ CharArray caDefault(strlen(homeDir)+17);
+ sprintf(caDefault.buf, %s/.vnc/x509_certs, homeDir);
+ delete [] homeDir;
+
+ if (!access(caDefault.buf, R_OK))
+x509ca.setDefaultStr(strdup(caDefault.buf));
else vlog.error(Failed to open ~/.vnc/x509_certs);
Question: Why do you need to do the access check?
In my option, a different default (dependend on the existance of a
file) is something unexpected.
Is the access check necessary, because the TLS setup bails out, if
there is no CA file?
In this case, I would change the TLS setup, so that it handles a
missing CA file like an empty CA file parameter.
+if (status GNUTLS_CERT_SIGNER_NOT_FOUND) {
+ size_t out_size;
+ char *homeDir = NULL;
+ char *out_buf;
+ char *certinfo;
+ int len = 0;
+
+ vlog.debug(certificate issuer unknown);
+
+ len = snprintf(NULL, 0, This certificate has been signed by an
unknown authority:\n\n%s\n\nDo you want to save it and continue?\n ,
info.data);
+ if (len 0)
+AuthFailureException(certificate decoding error);
+
+ vlog.debug(%s, info.data);
+
+ certinfo = (char*) malloc(len);
+ snprintf(certinfo, len, This certificate has been signed by an
unknown authority:\n\n%s\n\nDo you want to save it and continue? ,
info.data);
I would split the possibilty to accept and save. So you can first try
out a server without having to manually delete a certificate from a
file, if the server does not match the expectations.
On the other hand, ssh does the same.
Regards,
Martin Kögler
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 01/10] Add VeNCrypt security types
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
java/src/com/tigervnc/vncviewer/RfbProto.java | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/java/src/com/tigervnc/vncviewer/RfbProto.java
b/java/src/com/tigervnc/vncviewer/RfbProto.java
index 22cc113..dc7aa2e 100644
--- a/java/src/com/tigervnc/vncviewer/RfbProto.java
+++ b/java/src/com/tigervnc/vncviewer/RfbProto.java
@@ -47,10 +47,18 @@ class RfbProto {
// Security types
final static int
-SecTypeInvalid = 0,
-SecTypeNone= 1,
-SecTypeVncAuth = 2,
-SecTypeTight = 16;
+SecTypeInvalid = 0,
+SecTypeNone = 1,
+SecTypeVncAuth = 2,
+SecTypeTight = 16,
+SecTypeVeNCrypt = 19,
+SecTypePlain = 256,
+SecTypeTLSNone = 257,
+SecTypeTLSVnc= 258,
+SecTypeTLSPlain = 259,
+SecTypeX509None = 260,
+SecTypeX509Vnc = 261,
+SecTypeX509Plain = 262;
// Supported tunneling types
final static int
--
1.5.6.5
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 02/10] Implement VeNCrypt chooser
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
java/src/com/tigervnc/vncviewer/RfbProto.java | 33 +-
java/src/com/tigervnc/vncviewer/VncViewer.java | 43 ++-
2 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/java/src/com/tigervnc/vncviewer/RfbProto.java
b/java/src/com/tigervnc/vncviewer/RfbProto.java
index dc7aa2e..ab3c152 100644
--- a/java/src/com/tigervnc/vncviewer/RfbProto.java
+++ b/java/src/com/tigervnc/vncviewer/RfbProto.java
@@ -391,7 +391,8 @@ class RfbProto {
// Find first supported security type.
for (int i = 0; i nSecTypes; i++) {
- if (secTypes[i] == SecTypeNone || secTypes[i] == SecTypeVncAuth) {
+ if (secTypes[i] == SecTypeNone || secTypes[i] == SecTypeVncAuth
+ || secTypes[i] == SecTypeVeNCrypt) {
secType = secTypes[i];
break;
}
@@ -406,6 +407,36 @@ class RfbProto {
return secType;
}
+int authenticateVeNCrypt() throws Exception {
+ int majorVersion = readU8();
+ int minorVersion = readU8();
+ int Version = (majorVersion 8) | minorVersion;
+ if (Version 0x0002) {
+ os.write(0);
+ os.write(0);
+ throw new Exception(Server reported an unsupported VeNCrypt
version);
+ }
+ os.write(0);
+ os.write(2);
+ if (readU8() != 0)
+ throw new Exception(Server reported it could not support the
VeNCrypt version);
+ int nSecTypes = readU8();
+ int[] secTypes = new int[nSecTypes];
+ for(int i = 0; i nSecTypes; i++)
+ secTypes[i] = readU32();
+
+ for(int i = 0; i nSecTypes; i++)
+ switch(secTypes[i])
+ {
+ case SecTypeNone:
+ case SecTypeVncAuth:
+ writeInt(secTypes[i]);
+ return secTypes[i];
+ }
+
+ throw new Exception(No valid VeNCrypt sub-type);
+}
+
//
// Perform no authentication.
//
diff --git a/java/src/com/tigervnc/vncviewer/VncViewer.java
b/java/src/com/tigervnc/vncviewer/VncViewer.java
index 3c527ba..711b1c9 100644
--- a/java/src/com/tigervnc/vncviewer/VncViewer.java
+++ b/java/src/com/tigervnc/vncviewer/VncViewer.java
@@ -361,25 +361,34 @@ public class VncViewer extends java.applet.Applet
authType = secType;
}
-switch (authType) {
-case RfbProto.AuthNone:
- showConnectionStatus(No authentication needed);
- rfb.authenticateNone();
- break;
-case RfbProto.AuthVNC:
- showConnectionStatus(Performing standard VNC authentication);
- if (passwordParam != null) {
-rfb.authenticateVNC(passwordParam);
- } else {
-String pw = askPassword();
-rfb.authenticateVNC(pw);
- }
- break;
-default:
- throw new Exception(Unknown authentication scheme + authType);
-}
+doAuthentification(authType);
}
+void doAuthentification(int secType) throws Exception {
+ switch (secType) {
+ case RfbProto.SecTypeNone:
+ showConnectionStatus(No authentication needed);
+ rfb.authenticateNone();
+ break;
+ case RfbProto.SecTypeVncAuth:
+ showConnectionStatus(Performing standard VNC authentication);
+ if (passwordParam != null) {
+ rfb.authenticateVNC(passwordParam);
+ } else {
+ String pw = askPassword();
+ rfb.authenticateVNC(pw);
+ }
+ break;
+ case RfbProto.SecTypeVeNCrypt:
+ showConnectionStatus(VeNCrypt chooser);
+ secType = rfb.authenticateVeNCrypt();
+ doAuthentification(secType);
+ break;
+ default:
+ throw new Exception(Unknown authentication scheme + secType);
+ }
+}
+
//
// Show a message describing the connection status.
--
1.5.6.5
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 09/10] Remove TightVNC security type from server
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/ConnParams.cxx |2 +-
common/rfb/ConnParams.h|1 -
common/rfb/SConnection.cxx | 170
common/rfb/SConnection.h |9 ---
4 files changed, 1 insertions(+), 181 deletions(-)
diff --git a/common/rfb/ConnParams.cxx b/common/rfb/ConnParams.cxx
index 3ee3708..a636885 100644
--- a/common/rfb/ConnParams.cxx
+++ b/common/rfb/ConnParams.cxx
@@ -27,7 +27,7 @@
using namespace rfb;
ConnParams::ConnParams()
- : majorVersion(0), minorVersion(0), tightExtensionsEnabled(false),
+ : majorVersion(0), minorVersion(0),
width(0), height(0), useCopyRect(false),
supportsLocalCursor(false), supportsLocalXCursor(false),
supportsDesktopResize(false), supportsExtendedDesktopSize(false),
diff --git a/common/rfb/ConnParams.h b/common/rfb/ConnParams.h
index 54b5ada..c25e563 100644
--- a/common/rfb/ConnParams.h
+++ b/common/rfb/ConnParams.h
@@ -40,7 +40,6 @@ namespace rfb {
int majorVersion;
int minorVersion;
-bool tightExtensionsEnabled;
void setVersion(int major, int minor) {
majorVersion = major; minorVersion = minor;
diff --git a/common/rfb/SConnection.cxx b/common/rfb/SConnection.cxx
index fdd8da9..9d4d6ba 100644
--- a/common/rfb/SConnection.cxx
+++ b/common/rfb/SConnection.cxx
@@ -89,8 +89,6 @@ void SConnection::processMsg()
switch (state_) {
case RFBSTATE_PROTOCOL_VERSION: processVersionMsg(); break;
case RFBSTATE_SECURITY_TYPE:processSecurityTypeMsg(); break;
- case RFBSTATE_TIGHT_TUNN_TYPE: processTunnelTypeMsg(); break;
- case RFBSTATE_TIGHT_AUTH_TYPE: processAuthTypeMsg(); break;
case RFBSTATE_SECURITY: processSecurityMsg(); break;
case RFBSTATE_INITIALISATION: processInitMsg(); break;
case RFBSTATE_NORMAL: reader_-readMsg(); break;
@@ -167,9 +165,6 @@ void SConnection::processVersionMsg()
return;
}
- // Add a special security type to advertise TightVNC protocol extensions.
- // secTypes.push_back(secTypeTight);
-
// list supported security types for =3.7 clients
if (secTypes.empty())
@@ -188,107 +183,9 @@ void SConnection::processSecurityTypeMsg()
vlog.debug(processing security type message);
int secType = is-readU8();
- if (secType == secTypeTight) {
-vlog.info(Enabling TightVNC protocol extensions);
-cp.tightExtensionsEnabled = true;
-offerTunneling();
- } else {
-processSecurityType(secType);
- }
-}
-
-//
-// TightVNC-specific protocol initialization (tunneling, authentication)
-//
-
-void SConnection::offerTunneling()
-{
- vlog.debug(offering list of tunneling methods);
- int nTypes = 0;
-
- // Advertise our tunneling capabilities (currently, nothing to advertise).
- os-writeU32(nTypes);
- os-flush();
-
- if (nTypes) {
-// NOTE: Never executed in current version.
-state_ = RFBSTATE_TIGHT_TUNN_TYPE;
- } else {
-offerAuthentication();
- }
-}
-
-// NOTE: This function is never called in current version.
-void SConnection::processTunnelTypeMsg()
-{
- vlog.debug(processing tunneling type message (TightVNC extension));
- int tunnelType = is-readU32();
- vlog.error(unsupported tunneling type %d requested, ignoring, tunnelType);
- offerAuthentication();
-}
-
-void SConnection::offerAuthentication()
-{
- vlog.debug(offering list of authentication methods);
-
- // See processVersionMsg(), the code below is similar.
-
- std::listrdr::U8 secTypes;
- std::listrdr::U8::iterator i;
-
- // NOTE: In addition to standard security types, we might want to offer
- // TightVNC-specific authentication types. But currently we support
- // only the standard security types: secTypeNone and secTypeVncAuth.
- secTypes = security-GetEnabledSecTypes();
-
- CapsList caps;
- for (i = secTypes.begin(); i != secTypes.end(); i++) {
-// FIXME: Capability info should be provided by SSecurity objects.
-switch (*i) {
-case secTypeNone: caps.addStandard(*i, NOAUTH__); break;
-case secTypeVncAuth: caps.addStandard(*i, VNCAUTH_); break;
-default:
- // This should not ever happen.
- vlog.error(not offering unknown security type %d, (int)*i);
-}
- }
-
- if (caps.getSize() 1)
-throwConnFailedException(No supported security types);
-
- if (caps.includesOnly(secTypeNone)) {
-// Special case - if caps includes nothing else than secTypeNone, we send
-// an empty capability list and do not expect security type selection from
-// the client. Then, continue the protocol like if the client has selected
-// secTypeNone (starting at base protocol version 3.8, security result
-// will follow).
-os-writeU32(0);
-os-flush();
-processSecurityType(secTypeNone);
- } else {
-// Normal case - sending the list of authentication capabilities.
-os-writeU32(caps.getSize());
-caps.write(os);
-os-flush();
-state_ = RFBSTATE_TIGHT_AUTH_TYPE
[Tigervnc-devel] [PATCH 07/10] Implement X509 Security types
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
java/src/com/tigervnc/vncviewer/Makefile|4 +-
java/src/com/tigervnc/vncviewer/RfbProto.java |8 ++
java/src/com/tigervnc/vncviewer/VncViewer.java | 15
java/src/com/tigervnc/vncviewer/X509Tunnel.java | 103 +++
4 files changed, 128 insertions(+), 2 deletions(-)
create mode 100644 java/src/com/tigervnc/vncviewer/X509Tunnel.java
diff --git a/java/src/com/tigervnc/vncviewer/Makefile
b/java/src/com/tigervnc/vncviewer/Makefile
index 1abc15a..7e73d02 100644
--- a/java/src/com/tigervnc/vncviewer/Makefile
+++ b/java/src/com/tigervnc/vncviewer/Makefile
@@ -19,7 +19,7 @@ CLASSES = VncViewer.class RfbProto.class AuthPanel.class
VncCanvas.class \
SocketFactory.class HTTPConnectSocketFactory.class \
HTTPConnectSocket.class ReloginPanel.class \
InStream.class MemInStream.class ZlibInStream.class \
- TLSTunnelBase.class TLSTunnel.class Dialog.class MessageBox.class
+ TLSTunnelBase.class TLSTunnel.class X509Tunnel.class Dialog.class
MessageBox.class
SOURCES = VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java \
VncCanvas2.java \
@@ -29,7 +29,7 @@ SOURCES = VncViewer.java RfbProto.java AuthPanel.java
VncCanvas.java \
SocketFactory.java HTTPConnectSocketFactory.java \
HTTPConnectSocket.java ReloginPanel.java \
InStream.java MemInStream.java ZlibInStream.java \
- TLSTunnelBase.java TLSTunnel.java Dialog.java MessageBox.java
+ TLSTunnelBase.java TLSTunnel.java X509Tunnel.java Dialog.java
MessageBox.java
all: $(CLASSES) $(ARCHIVE)
diff --git a/java/src/com/tigervnc/vncviewer/RfbProto.java
b/java/src/com/tigervnc/vncviewer/RfbProto.java
index eb8ca93..e88d8e7 100644
--- a/java/src/com/tigervnc/vncviewer/RfbProto.java
+++ b/java/src/com/tigervnc/vncviewer/RfbProto.java
@@ -434,6 +434,9 @@ class RfbProto {
case SecTypeTLSNone:
case SecTypeTLSVnc:
case SecTypeTLSPlain:
+ case SecTypeX509None:
+ case SecTypeX509Vnc:
+ case SecTypeX509Plain:
writeInt(secTypes[i]);
return secTypes[i];
}
@@ -484,6 +487,11 @@ class RfbProto {
tunnel.setup (this);
}
+void authenticateX509() throws Exception {
+ X509Tunnel tunnel = new X509Tunnel(sock);
+ tunnel.setup (this);
+}
+
void authenticatePlain(String User, String Password) throws Exception {
byte[] user=User.getBytes();
byte[] password=Password.getBytes();
diff --git a/java/src/com/tigervnc/vncviewer/VncViewer.java
b/java/src/com/tigervnc/vncviewer/VncViewer.java
index 26c8238..1c6482a 100644
--- a/java/src/com/tigervnc/vncviewer/VncViewer.java
+++ b/java/src/com/tigervnc/vncviewer/VncViewer.java
@@ -407,6 +407,21 @@ public class VncViewer extends java.applet.Applet
rfb.authenticateTLS();
doAuthentification(RfbProto.SecTypePlain);
break;
+ case RfbProto.SecTypeX509None:
+ showConnectionStatus(X509None);
+ rfb.authenticateX509();
+ rfb.authenticateNone();
+ break;
+ case RfbProto.SecTypeX509Vnc:
+ showConnectionStatus(X509Vnc);
+ rfb.authenticateX509();
+ doAuthentification(RfbProto.SecTypeVncAuth);
+ break;
+ case RfbProto.SecTypeX509Plain:
+ showConnectionStatus(X509Plain);
+ rfb.authenticateX509();
+ doAuthentification(RfbProto.SecTypePlain);
+ break;
default:
throw new Exception(Unknown authentication scheme + secType);
}
diff --git a/java/src/com/tigervnc/vncviewer/X509Tunnel.java
b/java/src/com/tigervnc/vncviewer/X509Tunnel.java
new file mode 100644
index 000..ddc3f82
--- /dev/null
+++ b/java/src/com/tigervnc/vncviewer/X509Tunnel.java
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2003 Sun Microsystems, Inc.
+ * Copyright (C) 2003-2010 Martin Koegler
+ * Copyright (C) 2006 OCCAM Financial Technology
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+
+package com.tigervnc.vncviewer;
+
+import java.util.*;
+import java.net.*;
+import javax.net.ssl.*;
+import java.security.*;
+import
[Tigervnc-devel] [PATCH 00/10] VeNCrypt java support
This patchset updates the java code so that it can support all VeNCrypt security types. On thing I noticed, is that the tigervnc server and java client (but not the unix/win client) support the TightVNC security type. This security type is selected by default, if it is supported by server and client. It only supports None+VncAuth as security types. Therefore such a combination can not use any VeNCrypt security types. Instead it allows to first select a tunnel type and then an authentification type. The second feature is, that it allows the server to send capabilites to the client. As my encryption patches as Tightvnc tunneling types were not well received and the Tightvnc security type is not used in the C code, I took the aproach to disable the TightVNC security type (patch 8). patch 9+10 rip the support out of the code (optional). If somebody thinks, that the tightvnc security type should stay, we need to determine, how VeNCrypt should be added to the tightvnc protocol. Please note, that this does not affect the Tightvnc encoding. patch 1-7 update the java code to support all VeNCrypt security types: * patch 1 adds constants * patch 2 implements the chooser * patch 3 updates the authentification panel, so that it can ask for username or password * patch 4 implements the plain security type * patch 5 adds a message box implementation * patch 6 implements the TLS* security types * patch 7 implements the X509* security types There is room for lots of improvements (eg. X509 has no mean to get a certificate to check against = every certificate is flagged as untrusted), if others want to spend their time. After adding these patches, everything feature from VeNCrypt, I'm aware of, has been ported to tigervnc. A new release of tigervnc with precompiled, GNUTLS enabled windows binaries and the VeNCrypt project can be declared as superseded. Regards, Maritn Kögler Martin Koegler (10): 1. Add VeNCrypt security types 2. Implement VeNCrypt chooser 3. Support asking for a user name 4. Implement Plain Security type 5. Add simple Message Box implementation 6. Implment TLS security type 7. Implement X509 Security types 8. Disable TightVNC security type 9. Remove TightVNC security type from server 10. Remove Tightvnc Security type from java client common/rfb/ConnParams.cxx |2 +- common/rfb/ConnParams.h|1 - common/rfb/SConnection.cxx | 170 --- common/rfb/SConnection.h |9 - java/src/com/tigervnc/vncviewer/AuthPanel.java | 13 +- java/src/com/tigervnc/vncviewer/Dialog.java| 80 +++ java/src/com/tigervnc/vncviewer/Makefile |6 +- java/src/com/tigervnc/vncviewer/MessageBox.java| 82 +++ java/src/com/tigervnc/vncviewer/RfbProto.java | 227 +++- java/src/com/tigervnc/vncviewer/TLSTunnel.java | 51 + java/src/com/tigervnc/vncviewer/TLSTunnelBase.java | 86 java/src/com/tigervnc/vncviewer/VncViewer.java | 120 --- java/src/com/tigervnc/vncviewer/X509Tunnel.java| 103 + 13 files changed, 588 insertions(+), 362 deletions(-) create mode 100644 java/src/com/tigervnc/vncviewer/Dialog.java create mode 100644 java/src/com/tigervnc/vncviewer/MessageBox.java create mode 100644 java/src/com/tigervnc/vncviewer/TLSTunnel.java create mode 100644 java/src/com/tigervnc/vncviewer/TLSTunnelBase.java create mode 100644 java/src/com/tigervnc/vncviewer/X509Tunnel.java -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 05/10] Add simple Message Box implementation
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
java/src/com/tigervnc/vncviewer/Dialog.java | 80 ++
java/src/com/tigervnc/vncviewer/Makefile|6 +-
java/src/com/tigervnc/vncviewer/MessageBox.java | 82 +++
3 files changed, 166 insertions(+), 2 deletions(-)
create mode 100644 java/src/com/tigervnc/vncviewer/Dialog.java
create mode 100644 java/src/com/tigervnc/vncviewer/MessageBox.java
diff --git a/java/src/com/tigervnc/vncviewer/Dialog.java
b/java/src/com/tigervnc/vncviewer/Dialog.java
new file mode 100644
index 000..ba06b54
--- /dev/null
+++ b/java/src/com/tigervnc/vncviewer/Dialog.java
@@ -0,0 +1,80 @@
+/* Copyright (C) 2002-2005 RealVNC Ltd. All Rights Reserved.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+//
+// This Dialog class implements a pop-up dialog. This is needed because
+// apparently you can't use the standard AWT Dialog from within an applet. The
+// dialog can be made visible by calling its showDialog() method. Dialogs can
+// be modal or non-modal. For a modal dialog box, the showDialog() method must
+// be called from a thread other than the GUI thread, and it only returns when
+// the dialog box has been dismissed. For a non-modal dialog box, the
+// showDialog() method returns immediately.
+
+package com.tigervnc.vncviewer;
+
+import java.awt.*;
+
+class Dialog extends Frame {
+
+ public Dialog(boolean modal_) { modal = modal_; }
+
+ public boolean showDialog() {
+ok = false;
+done = false;
+initDialog();
+Dimension dpySize = getToolkit().getScreenSize();
+Dimension mySize = getSize();
+int x = (dpySize.width - mySize.width) / 2;
+int y = (dpySize.height - mySize.height) / 2;
+setLocation(x, y);
+show();
+if (!modal) return true;
+synchronized(this) {
+ try {
+while (!done)
+ wait();
+ } catch (InterruptedException e) {
+ }
+}
+return ok;
+ }
+
+ public void endDialog() {
+done = true;
+hide();
+if (modal) {
+ synchronized (this) {
+notify();
+ }
+}
+ }
+
+ // initDialog() can be overridden in a derived class. Typically it is used
+ // to make sure that checkboxes have the right state, etc.
+ public void initDialog() {}
+
+ public boolean handleEvent(Event event) {
+if (event.id == Event.WINDOW_DESTROY) {
+ ok = false;
+ endDialog();
+}
+return super.handleEvent(event);
+ }
+
+ protected boolean ok, done;
+ boolean modal;
+}
diff --git a/java/src/com/tigervnc/vncviewer/Makefile
b/java/src/com/tigervnc/vncviewer/Makefile
index 46752ab..0dba158 100644
--- a/java/src/com/tigervnc/vncviewer/Makefile
+++ b/java/src/com/tigervnc/vncviewer/Makefile
@@ -18,7 +18,8 @@ CLASSES = VncViewer.class RfbProto.class AuthPanel.class
VncCanvas.class \
RecordingFrame.class SessionRecorder.class \
SocketFactory.class HTTPConnectSocketFactory.class \
HTTPConnectSocket.class ReloginPanel.class \
- InStream.class MemInStream.class ZlibInStream.class
+ InStream.class MemInStream.class ZlibInStream.class \
+ Dialog.class MessageBox.class
SOURCES = VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java \
VncCanvas2.java \
@@ -27,7 +28,8 @@ SOURCES = VncViewer.java RfbProto.java AuthPanel.java
VncCanvas.java \
RecordingFrame.java SessionRecorder.java \
SocketFactory.java HTTPConnectSocketFactory.java \
HTTPConnectSocket.java ReloginPanel.java \
- InStream.java MemInStream.java ZlibInStream.java
+ InStream.java MemInStream.java ZlibInStream.java \
+ Dialog.java MessageBox.java
all: $(CLASSES) $(ARCHIVE)
diff --git a/java/src/com/tigervnc/vncviewer/MessageBox.java
b/java/src/com/tigervnc/vncviewer/MessageBox.java
new file mode 100644
index 000..123a970
--- /dev/null
+++ b/java/src/com/tigervnc/vncviewer/MessageBox.java
@@ -0,0 +1,82 @@
+/* Copyright (C) 2002-2005 RealVNC Ltd. All Rights Reserved.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version
[Tigervnc-devel] [PATCH 03/10] Support asking for a user name
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
java/src/com/tigervnc/vncviewer/AuthPanel.java | 13 +++--
java/src/com/tigervnc/vncviewer/VncViewer.java | 31 +++-
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/java/src/com/tigervnc/vncviewer/AuthPanel.java
b/java/src/com/tigervnc/vncviewer/AuthPanel.java
index 04d3bde..a23758e 100644
--- a/java/src/com/tigervnc/vncviewer/AuthPanel.java
+++ b/java/src/com/tigervnc/vncviewer/AuthPanel.java
@@ -31,22 +31,29 @@ class AuthPanel extends Panel implements ActionListener {
TextField passwordField;
Button okButton;
+ boolean AskPassword;
//
// Constructor.
//
- public AuthPanel(VncViewer viewer)
+ public AuthPanel(VncViewer viewer, boolean askpassword)
{
+AskPassword = askpassword;
Label titleLabel = new Label(VNC Authentication, Label.CENTER);
titleLabel.setFont(new Font(Helvetica, Font.BOLD, 18));
-Label promptLabel = new Label(Password:, Label.CENTER);
+Label promptLabel;
+if (AskPassword)
+ promptLabel = new Label(Password:, Label.CENTER);
+else
+ promptLabel = new Label(User:, Label.CENTER);
passwordField = new TextField(10);
passwordField.setForeground(Color.black);
passwordField.setBackground(Color.white);
-passwordField.setEchoChar('*');
+if (AskPassword)
+ passwordField.setEchoChar('*');
okButton = new Button(OK);
diff --git a/java/src/com/tigervnc/vncviewer/VncViewer.java
b/java/src/com/tigervnc/vncviewer/VncViewer.java
index 711b1c9..19541af 100644
--- a/java/src/com/tigervnc/vncviewer/VncViewer.java
+++ b/java/src/com/tigervnc/vncviewer/VncViewer.java
@@ -437,11 +437,40 @@ public class VncViewer extends java.applet.Applet
// Show an authentication panel.
//
+ String askUser() throws Exception
+ {
+showConnectionStatus(null);
+
+AuthPanel authPanel = new AuthPanel(this, false);
+
+GridBagConstraints gbc = new GridBagConstraints();
+gbc.gridwidth = GridBagConstraints.REMAINDER;
+gbc.anchor = GridBagConstraints.NORTHWEST;
+gbc.weightx = 1.0;
+gbc.weighty = 1.0;
+gbc.ipadx = 100;
+gbc.ipady = 50;
+gridbag.setConstraints(authPanel, gbc);
+vncContainer.add(authPanel);
+
+if (inSeparateFrame) {
+ vncFrame.pack();
+} else {
+ validate();
+}
+
+authPanel.moveFocusToDefaultField();
+String pw = authPanel.getPassword();
+vncContainer.remove(authPanel);
+
+return pw;
+ }
+
String askPassword() throws Exception
{
showConnectionStatus(null);
-AuthPanel authPanel = new AuthPanel(this);
+AuthPanel authPanel = new AuthPanel(this, true);
GridBagConstraints gbc = new GridBagConstraints();
gbc.gridwidth = GridBagConstraints.REMAINDER;
--
1.5.6.5
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 08/10] Disable TightVNC security type
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/SConnection.cxx|2 +-
java/src/com/tigervnc/vncviewer/RfbProto.java |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/rfb/SConnection.cxx b/common/rfb/SConnection.cxx
index bc4c982..fdd8da9 100644
--- a/common/rfb/SConnection.cxx
+++ b/common/rfb/SConnection.cxx
@@ -168,7 +168,7 @@ void SConnection::processVersionMsg()
}
// Add a special security type to advertise TightVNC protocol extensions.
- secTypes.push_back(secTypeTight);
+ // secTypes.push_back(secTypeTight);
// list supported security types for =3.7 clients
diff --git a/java/src/com/tigervnc/vncviewer/RfbProto.java
b/java/src/com/tigervnc/vncviewer/RfbProto.java
index e88d8e7..9834d3a 100644
--- a/java/src/com/tigervnc/vncviewer/RfbProto.java
+++ b/java/src/com/tigervnc/vncviewer/RfbProto.java
@@ -382,7 +382,7 @@ class RfbProto {
// Find out if the server supports TightVNC protocol extensions
for (int i = 0; i nSecTypes; i++) {
- if (secTypes[i] == SecTypeTight) {
+ if (secTypes[i] == SecTypeTight false) {
protocolTightVNC = true;
os.write(SecTypeTight);
return SecTypeTight;
--
1.5.6.5
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 06/10] Implment TLS security type
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
java/src/com/tigervnc/vncviewer/Makefile |4 +-
java/src/com/tigervnc/vncviewer/RfbProto.java | 13 +++
java/src/com/tigervnc/vncviewer/TLSTunnel.java | 51
java/src/com/tigervnc/vncviewer/TLSTunnelBase.java | 86
java/src/com/tigervnc/vncviewer/VncViewer.java | 15
5 files changed, 167 insertions(+), 2 deletions(-)
create mode 100644 java/src/com/tigervnc/vncviewer/TLSTunnel.java
create mode 100644 java/src/com/tigervnc/vncviewer/TLSTunnelBase.java
diff --git a/java/src/com/tigervnc/vncviewer/Makefile
b/java/src/com/tigervnc/vncviewer/Makefile
index 0dba158..1abc15a 100644
--- a/java/src/com/tigervnc/vncviewer/Makefile
+++ b/java/src/com/tigervnc/vncviewer/Makefile
@@ -19,7 +19,7 @@ CLASSES = VncViewer.class RfbProto.class AuthPanel.class
VncCanvas.class \
SocketFactory.class HTTPConnectSocketFactory.class \
HTTPConnectSocket.class ReloginPanel.class \
InStream.class MemInStream.class ZlibInStream.class \
- Dialog.class MessageBox.class
+ TLSTunnelBase.class TLSTunnel.class Dialog.class MessageBox.class
SOURCES = VncViewer.java RfbProto.java AuthPanel.java VncCanvas.java \
VncCanvas2.java \
@@ -29,7 +29,7 @@ SOURCES = VncViewer.java RfbProto.java AuthPanel.java
VncCanvas.java \
SocketFactory.java HTTPConnectSocketFactory.java \
HTTPConnectSocket.java ReloginPanel.java \
InStream.java MemInStream.java ZlibInStream.java \
- Dialog.java MessageBox.java
+ TLSTunnelBase.java TLSTunnel.java Dialog.java MessageBox.java
all: $(CLASSES) $(ARCHIVE)
diff --git a/java/src/com/tigervnc/vncviewer/RfbProto.java
b/java/src/com/tigervnc/vncviewer/RfbProto.java
index a0aade0..eb8ca93 100644
--- a/java/src/com/tigervnc/vncviewer/RfbProto.java
+++ b/java/src/com/tigervnc/vncviewer/RfbProto.java
@@ -431,6 +431,9 @@ class RfbProto {
case SecTypeNone:
case SecTypeVncAuth:
case SecTypePlain:
+ case SecTypeTLSNone:
+ case SecTypeTLSVnc:
+ case SecTypeTLSPlain:
writeInt(secTypes[i]);
return secTypes[i];
}
@@ -476,6 +479,11 @@ class RfbProto {
readSecurityResult(VNC authentication);
}
+void authenticateTLS() throws Exception {
+ TLSTunnel tunnel = new TLSTunnel(sock);
+ tunnel.setup (this);
+}
+
void authenticatePlain(String User, String Password) throws Exception {
byte[] user=User.getBytes();
byte[] password=Password.getBytes();
@@ -1545,4 +1553,9 @@ class RfbProto {
numBytesRead += 4;
return r;
}
+
+ public void setStreams(InputStream is_, OutputStream os_) {
+is = new DataInputStream(is_);
+os = os_;
+ }
}
diff --git a/java/src/com/tigervnc/vncviewer/TLSTunnel.java
b/java/src/com/tigervnc/vncviewer/TLSTunnel.java
new file mode 100644
index 000..00cfb4a
--- /dev/null
+++ b/java/src/com/tigervnc/vncviewer/TLSTunnel.java
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2003 Sun Microsystems, Inc.
+ * Copyright (C) 2003-2010 Martin Koegler
+ * Copyright (C) 2006 OCCAM Financial Technology
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+
+package com.tigervnc.vncviewer;
+
+import java.util.*;
+import java.net.*;
+import javax.net.ssl.*;
+
+public class TLSTunnel extends TLSTunnelBase
+{
+
+ public TLSTunnel (Socket sock_)
+ {
+super (sock_);
+ }
+
+
+ protected void setParam (SSLSocket sock)
+ {
+String[]supported;
+ArrayList enabled = new ArrayList ();
+
+supported = sock.getSupportedCipherSuites ();
+
+for (int i = 0; i supported.length; i++)
+ if (supported[i].matches (.*DH_anon.*))
+ enabled.add (supported[i]);
+
+sock.setEnabledCipherSuites ((String[])enabled.toArray (new String[0]));
+ }
+
+}
diff --git a/java/src/com/tigervnc/vncviewer/TLSTunnelBase.java
b/java/src/com/tigervnc/vncviewer/TLSTunnelBase.java
new file mode 100644
index 000..922e837
--- /dev/null
+++ b/java/src/com/tigervnc/vncviewer/TLSTunnelBase.java
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2003 Sun Microsystems, Inc.
+ * Copyright (C) 2003-2010 Martin Koegler
+ *
+ * This is free
Re: [Tigervnc-devel] [PATCH 00/10] VeNCrypt java support
On Sun, Nov 07, 2010 at 12:52:54PM -0600, DRC wrote: TurboVNC 1.0 uses the Tight security type to implement its auth extensions, and it relies upon the ability to advertise capabilities to the client using that mechanism. Whether or not the Tight security type actually does anything in our implementation, I think it is important to be able to advertise capabilities using that method. Tigervnc C client+server support VeNCrypt to advertise new auth types. I looked at the turbovnc sources: * UnixLogin is the same as the Plain security type [maybe a new/modifed password validator is necessary]. * OTP is on the network side the same as VncAuth - so it is something, that can be implemented by extending the the VncAuth password validation. The main question about the importance to advertise capabilities is: Why has nobody missed this fetature, when using the C client? Regards, Martin Kögler -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] build-xorg improvements
On Fri, Oct 01, 2010 at 02:38:53PM -0500, DRC wrote: I agree. SourceForge has mediawiki pre-installed, so projects such as ours can choose to use that for our web site instead of a static page. Last time I looked at mediawiki offered by SoureForge, edit rights must be granted by the wiki admin to each user. Assignmend of Wikipedia styled edit rights for everyone were not possible. Regards, Martin Kögler -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Workaround for older gnutls
On Wed, Sep 08, 2010 at 02:14:55AM -0500, DRC wrote:
However, when I attempted to apply the patch to work around this, I got
a worse build error:
gcc4 -DHAVE_CONFIG_H -I. -I/home/drc/worksrc/tigervnc/common/os -I../..
-I/home/drc/worksrc/tigervnc/common -O3 -static-libgcc -fPIC -Wall -MT
libos_la-net.lo -MD -MP -MF .deps/libos_la-net.Tpo -c
/home/drc/worksrc/tigervnc/common/os/net.c -fPIC -DPIC -o
.libs/libos_la-net.o
In file included from /usr/include/stdlib.h:33,
from /home/drc/worksrc/tigervnc/common/os/net.c:23:
/usr/lib/gcc/x86_64-redhat-linux5E/4.1.2/include/stddef.h:214: error:
expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef'
In file included from /home/drc/worksrc/tigervnc/common/os/net.c:23:
/usr/include/stdlib.h:140: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '__ctype_get_mb_cur_max'
In file included from /usr/include/sys/types.h:266,
from /usr/include/stdlib.h:433,
from /home/drc/worksrc/tigervnc/common/os/net.c:23:
/usr/include/bits/pthreadtypes.h:48: error: expected
specifier-qualifier-list before 'size_t'
In file included from /home/drc/worksrc/tigervnc/common/os/net.c:23:
/usr/include/stdlib.h:450: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/stdlib.h:480: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/stdlib.h:482: error: nonnull argument with out-of-range
operand number (argument 1, operand 4)
/usr/include/stdlib.h:584: error: expected ')' before '__size'
/usr/include/stdlib.h:586: error: expected ')' before '__nmemb'
/usr/include/stdlib.h:595: error: expected declaration specifiers or
'...' before 'size_t'
In file included from /usr/include/stdlib.h:606,
from /home/drc/worksrc/tigervnc/common/os/net.c:23:
/usr/include/alloca.h:33: error: expected ')' before '__size'
In file included from /home/drc/worksrc/tigervnc/common/os/net.c:23:
I can not imaging, how such errors can happen.
This test only adds the following to config.h:
| /* Is gnutls_set_global_errno present */
| #define gnutls_transport_set_global_errno(A) do { errno = (A); } while(0)
|
So any code not refering to gnutls_transport_set_global_errno should
not be affected.
Can you check, what is added to your config.h? My first guess is, that
some garbage is at the end of that file, which breaks everything after
including it.
Regards,
Martin Kögler
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Implement Plain in the client
On Fri, Sep 03, 2010 at 07:50:07AM -0600, DRC wrote: On 9/3/10 12:00 AM, Martin Koegler wrote: The client side honors the Security Type order of the server - code for using the client side order was removed with Remove unused CConnection::setClientSecTypeOrder function on Jul 20 2010. So does that mean if Plain is enabled on the server and put into the top of the order, a user would not have to explicitly enable it with -SecurityType on the client? The client skips security types, if it is not somewhere in its SecurityType parameter. mfg Martin Kögler -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH] Implement Plain in the client
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/CSecurityPlain.cxx | 46 +
common/rfb/CSecurityPlain.h | 36
common/rfb/Makefile.am|4 +-
common/rfb/Security.cxx | 10 -
4 files changed, 93 insertions(+), 3 deletions(-)
create mode 100644 common/rfb/CSecurityPlain.cxx
create mode 100644 common/rfb/CSecurityPlain.h
diff --git a/common/rfb/CSecurityPlain.cxx b/common/rfb/CSecurityPlain.cxx
new file mode 100644
index 000..f5f7c1a
--- /dev/null
+++ b/common/rfb/CSecurityPlain.cxx
@@ -0,0 +1,46 @@
+/* Copyright (C) 2005 Martin Kögler
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+
+#include rfb/CConnection.h
+#include rfb/CSecurityPlain.h
+#include rfb/UserPasswdGetter.h
+#include rfb/util.h
+
+using namespace rfb;
+
+CSecurityPlain::CSecurityPlain()
+{
+}
+
+bool CSecurityPlain::processMsg(CConnection* cc)
+{
+ rdr::OutStream* os = cc-getOutStream();
+
+ CharArray username;
+ CharArray password;
+
+ (CSecurity::upg)-getUserPasswd(username.buf, password.buf);
+
+ // Return the response to the server
+ os-writeU32(strlen(username.buf));
+ os-writeU32(strlen(password.buf));
+ os-writeBytes(username.buf,strlen(username.buf));
+ os-writeBytes(password.buf,strlen(password.buf));
+ os-flush();
+ return true;
+}
diff --git a/common/rfb/CSecurityPlain.h b/common/rfb/CSecurityPlain.h
new file mode 100644
index 000..30d4850
--- /dev/null
+++ b/common/rfb/CSecurityPlain.h
@@ -0,0 +1,36 @@
+/* Copyright (C) 2005 Martin Kögler
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this software; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ */
+#ifndef __RFB_CSECURITYPLAIN_H__
+#define __RFB_CSECURITYPLAIN_H__
+
+#include rfb/CSecurity.h
+#include rfb/Security.h
+
+namespace rfb {
+
+ class UserPasswdGetter;
+
+ class CSecurityPlain : public CSecurity {
+ public:
+CSecurityPlain();
+virtual bool processMsg(CConnection* cc);
+virtual int getType() const {return secTypePlain;};
+virtual const char* description() const {return ask for username and
password;}
+ };
+}
+#endif
diff --git a/common/rfb/Makefile.am b/common/rfb/Makefile.am
index 78c959f..4e5bbd7 100644
--- a/common/rfb/Makefile.am
+++ b/common/rfb/Makefile.am
@@ -8,7 +8,7 @@ HDRS = Blacklist.h CapsContainer.h CapsList.h CConnection.h \
CMsgHandler.h CMsgReader.h CMsgReaderV3.h CMsgWriter.h \
CMsgWriterV3.h ColourCube.h ColourMap.h ComparingUpdateTracker.h \
Configuration.h ConnParams.h CSecurity.h CSecurityNone.h \
- CSecurityStack.h CSecurityVeNCrypt.h \
+ CSecurityPlain.h CSecurityStack.h CSecurityVeNCrypt.h \
CSecurityVncAuth.h Cursor.h Decoder.h d3des.h Encoder.h \
encodings.h Exception.h hextileConstants.h hextileDecode.h \
HextileDecoder.h hextileEncodeBetter.h hextileEncode.h \
@@ -30,7 +30,7 @@ HDRS = Blacklist.h CapsContainer.h CapsList.h CConnection.h \
librfb_la_SOURCES = $(HDRS) Blacklist.cxx CConnection.cxx CMsgHandler.cxx \
CMsgReader.cxx CMsgReaderV3.cxx CMsgWriter.cxx CMsgWriterV3.cxx \
- CSecurityStack.cxx CSecurityVeNCrypt.cxx \
+ CSecurityPlain.cxx CSecurityStack.cxx CSecurityVeNCrypt.cxx \
CSecurityVncAuth.cxx CapsContainer.cxx CapsList.cxx \
ComparingUpdateTracker.cxx Configuration.cxx ConnParams.cxx \
Cursor.cxx Decoder.cxx d3des.c Encoder.cxx \
diff --git a/common/rfb/Security.cxx b/common/rfb/Security.cxx
index 71e45de..708c10a 100644
--- a/common/rfb/Security.cxx
+++ b/common/rfb/Security.cxx
@@ -31,6 +31,7 @@
#include rfb/CSecurityStack.h
#include rfb/CSecurityVeNCrypt.h
Re: [Tigervnc-devel] [PATCH] Pam based Plain implementation
On Thu, Sep 02, 2010 at 04:14:20PM +0200, Adam Tkac wrote: On Thu, Sep 02, 2010 at 09:05:54AM +0200, Martin Koegler wrote: Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at --- Windows password validator is contained in the VeNCrypt sources. Ok, I will port it to TigerVNC. *Plain implementation with PAM support has been commited as r4128 with little improvements, thanks for your work! Some files are missing. Regards, Martin Kögler -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Provide default pixel format for depth 32
On Wed, Aug 25, 2010 at 03:40:29PM +0200, Adam Tkac wrote: On Tue, Aug 24, 2010 at 08:05:38AM +0200, Martin Koegler wrote: Libraries like qt segfault, if reader is enabled but this information is not set Commited with little modifications as r4124. Thanks for the patch. Your patch leaves pvfb-blueBits, pvfb-redBits, pvfb-greenBits and pvfb-rgbNotBgr undefined but uses their values, if the pixelformat has not been specifed on the command line and the depth is not 16 or 32. Regards, Martin Kögler -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH 00/13] SecurityType handling
On Thu, Jul 22, 2010 at 04:02:52PM -0500, DRC wrote: This makes the use of extended authentication types somewhat useless from the point of view of a SysAdmin, though. If there is not a way for them to enforce, or at least strongly encourage, the use of secure authentication on a system-wide level, then any user can choose to use VncAuth or VncNone. A SysAdmin can't prevent a user from doing this. For normal (shell) user processes, he can only suggest defaults. If a sysadmin wants to control VNC use, has to: * Install a firewall on the server preventing inbound connection * Start vnc on some ports under a system user (eg. via inetd) Even in that case, the user can still start his own Xvnc server, but he needs to tunnel remote access. The way we do things in TurboVNC is to have a separate config file, /etc/turbovncserver-auth.conf, which is hard-coded into the Xvnc executable. Thus, the user has no ability to override this without re-compiling Xvnc (which, trust me, isn't something that a user is going to do with TigerVNC. It's hard enough for us to compile it!) If the defaults are sensible, the user will not override them. If the user is annoyed by the sysadmin setting, he will search for alternatives. The user is not required to recompile it himself. User are likely to start exchanging modifed, precompiled version. If TurboVNC has not taken extra precautions, a 1-2 lines shell script should be sufficient to prevent it from using the sysadmin defaults. If I understand correctly, then using the -securityTypes argument to vncserver and vncviewer addresses most of this, but correct me if I'm wrong. There is no config file support in Xvnc and vncviewer. I will need to implement an auth config file of some sort if I ever deign to port the PAM authentication support over to TigerVNC, so that would be the appropriate time to revisit having some sort of mechanism for the SysAdmin to specify the security types globally. PAM support would not fit in a normal config file. It requires a file /etc/pam.d/service-name specifying the list of pam modules. The Plain security needs only needs another option specifing, that it should use a pam based password validator and maybe allows to override the service-name passed to PAM. Regards, Martin Kögler -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH 00/13] SecurityType handling
On Wed, Jul 21, 2010 at 12:48:05PM -0500, DRC wrote: On 7/21/10 3:16 AM, Adam Tkac wrote: This is a valid argument but I would like to see feedback from other TigerVNC developers to decide which types should be enabled by default. I will open a separate thread for this. I am joining into this discussion late, so I don't think I fully understand how the system currently works, but IMHO, the way it should work is as follows: -- A set of allowed security types can be configured for the VNC server. It should be possible for a SysAdmin to specify this in a central config file, which will take precedence over command line options or per-user config files (thus, if a SysAdmin decides, for instance, to disable the use of VncAuth, the user can't override this decision.) If the user has shell access and the vnc server is started using the uid of the user by the user (eg. not by inetd), a user can bypass the sysadmin setting (eg. by starting a modified version from $HOME). As Xvnc can run as any user, I would like to stick to the normal user unix default for such unprivileged programs: parameters take precedence over config file. -- The first entry in the set of allowed security types becomes the default security type for the viewer, but the viewer can override this and use any of the other allowed security types. I agree with this - this will require to enable all security types by default in the viewer. As the (unused) client preference setting has been removed, the viewer will always select the first security type of the server, which is also enabled on the client. -- The default set of allowed security types for the server is the set of all security types that TigerVNC supports, with VncAuth being the first entry and VncNone being the last. Thus, any viewers that do not override the default will revert to using the legacy VNC password authentication. However, the SysAdmin can change the set of allowed security types on the server side to force all viewers to use something more secure than VncAuth. I would not enable the *None by default in the server, as anybody can connect to it. Its easy to start Xvnc and forgetting to set SecurityTypes. If I understand correctly, then using the -securityTypes argument to vncserver and vncviewer addresses most of this, but correct me if I'm wrong. There is no config file support in Xvnc and vncviewer. Regards, Martin Kögler -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 00/13] SecurityType handling
This patchset contains various fixes/changes related to the security type handling. 1 removes a leftover declaration 2-4 fixes the security type parameter in the vncviewer. The viewer has the problem, that the handshake phase in the viewer uses a hardcoded list containing all security types. The code creating CSecurity only honors the SecurityTypes parameter, which only defaults to VncAuth. If multiple types are active in the server, vncviewer can select a type disallowed by SecurityTypes. The problem is fixed by: * Overriding the default value of SecurityTypes in the viewer * Using the content of SecurityTypes in the handshake phase The rest 5-12 implements a seamless integration of the VeNCrypt security type. The VeNCrypt security type was intended to be a generic selector allowing to extend the number of possible security types from 2^8 to 2^32, so that every little project can get their security types. The VeNCrypt code allowed to also negotiate traditional security types like None and VncAuth. This patch aligns tigervnc with the VeNCrypt behaviour. With the patch, only the SecurityTypes parameter is left. It allows specifing old and new security types in one list, eg: VncAuth,TLSNone,None The code will negotiate the first type of the server SecurityTypes paramter, which is also enabled on the client (unless the viewer would enable the client preference option). Internally, server and client will always add VeNCrypt as first element of their list and add all old security types of SecurityTypes after that. So if client or server don't support VeNCrypt, they can only negotiate None or VncAuth. If both support VeNCrypt, the server will send the full list also containing TLSNone, TLSVnc, ... As a side effect, the VeNCrypt selector is now always compiled in. HAVE_GNUTLS only disables compiling the TLS based security types. 7 enhance the normal security type parsing code, so that it can support 2^32 security types. 6+8+11+12 integrate the VeNCrypt security types into the normal code Regards, Martin Kögler Martin Koegler (13): 1) Remove leftover code 2) Allow changing the default value of string parameters 3) Fix default security type setting of vncviewer 4) Use SecurityTypes Parameter in vncviewer 5) Variable is only used as CSecurity/SSecurity 6) Move VeNCrypt security types 7) Use U32 as internal SecurityType type 8) Support VeNCrypt Security types in normal security type parser 9) Add logging code 10) Pass Security instance to VeNCrypt security 11) Use SecurityType also as configuration for VeNCrypt 12) Create VeNCrypt security types in Security class 13) Move x509 certificate parameters common/rfb/CConnection.cxx | 30 - common/rfb/CConnection.h |8 --- common/rfb/CSecurityVeNCrypt.cxx | 52 +++ common/rfb/CSecurityVeNCrypt.h |7 +- common/rfb/Configuration.cxx |6 ++ common/rfb/Configuration.h |1 + common/rfb/Makefile.am | 16 +++-- common/rfb/SSecurityPlain.cxx|4 - common/rfb/SSecurityPlain.h |4 - common/rfb/SSecurityVeNCrypt.cxx | 128 ++ common/rfb/SSecurityVeNCrypt.h | 27 +--- common/rfb/Security.cxx | 105 ++- common/rfb/Security.h| 31 ++--- unix/vncviewer/CConn.cxx |3 - unix/vncviewer/vncviewer.cxx |1 + win/vncviewer/CConn.cxx |2 - win/vncviewer/CConn.h|1 - win/vncviewer/vncviewer.cxx |1 + 18 files changed, 165 insertions(+), 262 deletions(-) -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 06/13] Move VeNCrypt security types
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/SSecurityVeNCrypt.h |9 -
common/rfb/Security.h |9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/common/rfb/SSecurityVeNCrypt.h b/common/rfb/SSecurityVeNCrypt.h
index d44a6a2..6e84465 100644
--- a/common/rfb/SSecurityVeNCrypt.h
+++ b/common/rfb/SSecurityVeNCrypt.h
@@ -38,15 +38,6 @@
namespace rfb {
- /* VeNCrypt subtypes */
- const int secTypePlain = 256;
- const int secTypeTLSNone = 257;
- const int secTypeTLSVnc = 258;
- const int secTypeTLSPlain= 259;
- const int secTypeX509None= 260;
- const int secTypeX509Vnc = 261;
- const int secTypeX509Plain = 262;
-
class SSecurityVeNCrypt : public SSecurity {
public:
SSecurityVeNCrypt(void);
diff --git a/common/rfb/Security.h b/common/rfb/Security.h
index dd5343a..4990a54 100644
--- a/common/rfb/Security.h
+++ b/common/rfb/Security.h
@@ -45,6 +45,15 @@ namespace rfb {
const rdr::U8 secTypeTLS = 18;
const rdr::U8 secTypeVeNCrypt= 19;
+ /* VeNCrypt subtypes */
+ const int secTypePlain = 256;
+ const int secTypeTLSNone = 257;
+ const int secTypeTLSVnc = 258;
+ const int secTypeTLSPlain= 259;
+ const int secTypeX509None= 260;
+ const int secTypeX509Vnc = 261;
+ const int secTypeX509Plain = 262;
+
// result types
const rdr::U32 secResultOK = 0;
--
1.6.4.2
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 04/13] Use SecurityTypes Parameter in vncviewer
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/CConnection.cxx | 30 ++
common/rfb/CConnection.h |8
unix/vncviewer/CConn.cxx |3 ---
win/vncviewer/CConn.cxx|2 --
4 files changed, 14 insertions(+), 29 deletions(-)
diff --git a/common/rfb/CConnection.cxx b/common/rfb/CConnection.cxx
index ac3c35e..21a1faa 100644
--- a/common/rfb/CConnection.cxx
+++ b/common/rfb/CConnection.cxx
@@ -33,7 +33,7 @@ static LogWriter vlog(CConnection);
CConnection::CConnection()
: csecurity(0), is(0), os(0), reader_(0), writer_(0),
-shared(false), nSecTypes(0), clientSecTypeOrder(false),
+shared(false), clientSecTypeOrder(false),
state_(RFBSTATE_UNINITIALISED), useProtocol3_3(false)
{
security = new Security();
@@ -59,13 +59,6 @@ void CConnection::setStreams(rdr::InStream* is_,
rdr::OutStream* os_)
os = os_;
}
-void CConnection::addSecType(rdr::U8 secType)
-{
- if (nSecTypes == maxSecTypes)
-throw Exception(too many security types);
- secTypes[nSecTypes++] = secType;
-}
-
void CConnection::setClientSecTypeOrder(bool clientOrder) {
clientSecTypeOrder = clientOrder;
}
@@ -133,6 +126,9 @@ void CConnection::processSecurityTypesMsg()
int secType = secTypeInvalid;
+ std::listrdr::U8 secTypes;
+ secTypes = security-GetEnabledSecTypes();
+
if (cp.isVersion(3,3)) {
// legacy 3.3 server may only offer vnc authentication or none
@@ -142,10 +138,10 @@ void CConnection::processSecurityTypesMsg()
throwConnFailedException();
} else if (secType == secTypeNone || secType == secTypeVncAuth) {
- int j;
- for (j = 0; j nSecTypes; j++)
-if (secTypes[j] == secType) break;
- if (j == nSecTypes)
+ std::listrdr::U8::iterator i;
+ for (i = secTypes.begin(); i != secTypes.end(); i++)
+if (*i == secType) break;
+ if (i == secTypes.end())
secType = secTypeInvalid;
} else {
vlog.error(Unknown 3.3 security type %d, secType);
@@ -160,7 +156,7 @@ void CConnection::processSecurityTypesMsg()
if (nServerSecTypes == 0)
throwConnFailedException();
-int secTypePos = nSecTypes;
+int secTypePos = secTypes.size();
for (int i = 0; i nServerSecTypes; i++) {
rdr::U8 serverSecType = is-readU8();
vlog.debug(Server offers security type %s(%d),
@@ -171,9 +167,11 @@ void CConnection::processSecurityTypesMsg()
// we keep trying types, to find the one that matches and
// which appears first in the client's list of supported types.
if (secType == secTypeInvalid || clientSecTypeOrder) {
-for (int j = 0; j nSecTypes; j++) {
- if (secTypes[j] == serverSecType j secTypePos) {
-secType = secTypes[j];
+std::listrdr::U8::iterator i;
+int j;
+for (j = 0, i = secTypes.begin(); i != secTypes.end(); i++, j++) {
+ if (*i == serverSecType j secTypePos) {
+secType = *i;
secTypePos = j;
break;
}
diff --git a/common/rfb/CConnection.h b/common/rfb/CConnection.h
index 6d3783a..832e061 100644
--- a/common/rfb/CConnection.h
+++ b/common/rfb/CConnection.h
@@ -59,11 +59,6 @@ namespace rfb {
// (i.e. SConnection will not delete them).
void setStreams(rdr::InStream* is, rdr::OutStream* os);
-// addSecType() should be called once for each security type which the
-// client supports. The order in which they're added is such that the
-// first one is most preferred.
-void addSecType(rdr::U8 secType);
-
// setClientSecTypeOrder() determines whether the client should obey
// the server's security type preference, by picking the first server
security
// type that the client supports, or whether it should pick the first type
@@ -163,9 +158,6 @@ namespace rfb {
CMsgWriter* writer_;
bool deleteStreamsWhenDone;
bool shared;
-enum { maxSecTypes = 8 };
-int nSecTypes;
-rdr::U8 secTypes[maxSecTypes];
bool clientSecTypeOrder;
stateEnum state_;
diff --git a/unix/vncviewer/CConn.cxx b/unix/vncviewer/CConn.cxx
index 406e167..8d311c3 100644
--- a/unix/vncviewer/CConn.cxx
+++ b/unix/vncviewer/CConn.cxx
@@ -69,9 +69,6 @@ CConn::CConn(Display* dpy_, int argc_, char** argv_,
network::Socket* sock_,
menuKeysym = XStringToKeysym(menuKeyStr.buf);
setShared(shared);
- addSecType(secTypeNone);
- addSecType(secTypeVncAuth);
- addSecType(secTypeVeNCrypt);
CSecurity::upg = this; /* Security instance is created in CConnection
costructor. */
CharArray encStr(preferredEncoding.getData());
diff --git a/win/vncviewer/CConn.cxx b/win/vncviewer/CConn.cxx
index 511c412..03fefdb 100644
--- a/win/vncviewer/CConn.cxx
+++ b/win/vncviewer/CConn.cxx
@@ -99,8 +99,6 @@ bool CConn::initialise(network::Socket* s, bool reverse) {
applyOptions(options);
// - Set which auth schemes we support, in order of preference
- addSecType
[Tigervnc-devel] [PATCH 02/13] Allow changing the default value of string parameters
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/Configuration.cxx |6 ++
common/rfb/Configuration.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/common/rfb/Configuration.cxx b/common/rfb/Configuration.cxx
index 6811a79..e9eee1a 100644
--- a/common/rfb/Configuration.cxx
+++ b/common/rfb/Configuration.cxx
@@ -418,6 +418,12 @@ StringParameter::~StringParameter() {
strFree(value);
}
+void StringParameter::setDefaultStr(const char* v) {
+ def_value = v;
+ strFree(value);
+ value = strDup(v);
+}
+
bool StringParameter::setParam(const char* v) {
LOCK_CONFIG;
if (immutable) return true;
diff --git a/common/rfb/Configuration.h b/common/rfb/Configuration.h
index 3e21b18..c994f62 100644
--- a/common/rfb/Configuration.h
+++ b/common/rfb/Configuration.h
@@ -240,6 +240,7 @@ namespace rfb {
virtual bool setParam(const char* value);
virtual char* getDefaultStr() const;
virtual char* getValueStr() const;
+virtual void setDefaultStr(const char* v);
// getData() returns a copy of the data - it must be delete[]d by the
// caller.
--
1.6.4.2
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 08/13] Support VeNCrypt Security types in normal security type parser
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at --- common/rfb/Security.cxx | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/common/rfb/Security.cxx b/common/rfb/Security.cxx index ad51f1b..86328b3 100644 --- a/common/rfb/Security.cxx +++ b/common/rfb/Security.cxx @@ -148,6 +148,15 @@ rdr::U32 rfb::secTypeNum(const char* name) if (strcasecmp(name, SSPI) == 0) return secTypeSSPI; if (strcasecmp(name, SSPIne) == 0) return secTypeSSPIne; if (strcasecmp(name, VeNCrypt) == 0) return secTypeVeNCrypt; + + /* VeNCrypt */ + if (strcasecmp(name, TLSNone) == 0)return secTypeTLSNone; + if (strcasecmp(name, TLSVnc) == 0) return secTypeTLSVnc; + if (strcasecmp(name, TLSPlain) == 0) return secTypeTLSPlain; + if (strcasecmp(name, X509None) == 0) return secTypeX509None; + if (strcasecmp(name, X509Vnc) == 0)return secTypeX509Vnc; + if (strcasecmp(name, X509Plain) == 0) return secTypeX509Plain; + return secTypeInvalid; } @@ -162,6 +171,15 @@ const char* rfb::secTypeName(rdr::U32 num) case secTypeSSPI: return SSPI; case secTypeSSPIne: return SSPIne; case secTypeVeNCrypt: return VeNCrypt; + /* VeNCrypt */ + case secTypePlain: return Plain; + case secTypeTLSNone:return TLSNone; + case secTypeTLSVnc: return TLSVnc; + case secTypeTLSPlain: return TLSPlain; + case secTypeX509None: return X509None; + case secTypeX509Vnc:return X509Vnc; + case secTypeX509Plain: return X509Plain; + default:return [unknown secType]; } } -- 1.6.4.2 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [PATCH 07/13] Use U32 as internal SecurityType type
Signed-off-by: Martin Koegler mkoeg...@auto.tuwien.ac.at
---
common/rfb/Security.cxx | 34 +++---
common/rfb/Security.h | 21 +++--
2 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/common/rfb/Security.cxx b/common/rfb/Security.cxx
index 8ea7572..ad51f1b 100644
--- a/common/rfb/Security.cxx
+++ b/common/rfb/Security.cxx
@@ -68,9 +68,21 @@ Security::Security(void)
delete secTypesStr;
}
-void Security::EnableSecType(U8 secType)
+const std::listrdr::U8 Security::GetEnabledSecTypes(void)
{
- listU8::iterator i;
+ std::listrdr::U8 result;
+ listU32::iterator i;
+
+ for (i = enabledSecTypes.begin(); i != enabledSecTypes.end(); i++)
+if (*i 0x100)
+ result.push_back(*i);
+
+ return result;
+}
+
+void Security::EnableSecType(U32 secType)
+{
+ listU32::iterator i;
for (i = enabledSecTypes.begin(); i != enabledSecTypes.end(); i++)
if (*i == secType)
@@ -79,9 +91,9 @@ void Security::EnableSecType(U8 secType)
enabledSecTypes.push_back(secType);
}
-bool Security::IsSupported(U8 secType)
+bool Security::IsSupported(U32 secType)
{
- listU8::iterator i;
+ listU32::iterator i;
for (i = enabledSecTypes.begin(); i != enabledSecTypes.end(); i++)
if (*i == secType)
@@ -90,7 +102,7 @@ bool Security::IsSupported(U8 secType)
return false;
}
-SSecurity* Security::GetSSecurity(U8 secType)
+SSecurity* Security::GetSSecurity(U32 secType)
{
if (!IsSupported(secType))
goto bail;
@@ -107,7 +119,7 @@ bail:
throw Exception(Security type not supported);
}
-CSecurity* Security::GetCSecurity(U8 secType)
+CSecurity* Security::GetCSecurity(U32 secType)
{
assert (CSecurity::upg != NULL); /* (upg == NULL) means bug in the viewer */
@@ -126,7 +138,7 @@ bail:
throw Exception(Security type not supported);
}
-rdr::U8 rfb::secTypeNum(const char* name)
+rdr::U32 rfb::secTypeNum(const char* name)
{
if (strcasecmp(name, None) == 0) return secTypeNone;
if (strcasecmp(name, VncAuth) == 0)return secTypeVncAuth;
@@ -139,7 +151,7 @@ rdr::U8 rfb::secTypeNum(const char* name)
return secTypeInvalid;
}
-const char* rfb::secTypeName(rdr::U8 num)
+const char* rfb::secTypeName(rdr::U32 num)
{
switch (num) {
case secTypeNone: return None;
@@ -154,13 +166,13 @@ const char* rfb::secTypeName(rdr::U8 num)
}
}
-std::listrdr::U8 rfb::parseSecTypes(const char* types_)
+std::listrdr::U32 rfb::parseSecTypes(const char* types_)
{
- std::listrdr::U8 result;
+ std::listrdr::U32 result;
CharArray types(strDup(types_)), type;
while (types.buf) {
strSplit(types.buf, ',', type.buf, types.buf);
-rdr::U8 typeNum = secTypeNum(type.buf);
+rdr::U32 typeNum = secTypeNum(type.buf);
if (typeNum != secTypeInvalid)
result.push_back(typeNum);
}
diff --git a/common/rfb/Security.h b/common/rfb/Security.h
index 4990a54..837f6b4 100644
--- a/common/rfb/Security.h
+++ b/common/rfb/Security.h
@@ -68,21 +68,22 @@ namespace rfb {
Security(void);
/* Enable/Disable certain security type */
-void EnableSecType(rdr::U8 secType);
-void DisableSecType(rdr::U8 secType) { enabledSecTypes.remove(secType); }
+void EnableSecType(rdr::U32 secType);
+void DisableSecType(rdr::U32 secType) { enabledSecTypes.remove(secType); }
/* Check if certain type is supported */
-bool IsSupported(rdr::U8 secType);
+bool IsSupported(rdr::U32 secType);
/* Get list of enabled security types */
-const std::listrdr::U8 GetEnabledSecTypes(void)
+const std::listrdr::U8 GetEnabledSecTypes(void);
+const std::listrdr::U32 GetEnabledExtSecTypes(void)
{ return enabledSecTypes; }
/* Create server side SSecurity class instance */
-SSecurity* GetSSecurity(rdr::U8 secType);
+SSecurity* GetSSecurity(rdr::U32 secType);
/* Create client side CSecurity class instance */
-CSecurity* GetCSecurity(rdr::U8 secType);
+CSecurity* GetCSecurity(rdr::U32 secType);
static StringParameter secTypes;
static void enableClientTypes();
@@ -92,12 +93,12 @@ namespace rfb {
* only in viewer-side code and MUST be set by viewer.
*/
private:
-std::listrdr::U8 enabledSecTypes;
+std::listrdr::U32 enabledSecTypes;
};
- const char* secTypeName(rdr::U8 num);
- rdr::U8 secTypeNum(const char* name);
- std::listrdr::U8 parseSecTypes(const char* types);
+ const char* secTypeName(rdr::U32 num);
+ rdr::U32 secTypeNum(const char* name);
+ std::listrdr::U32 parseSecTypes(const char* types);
}
#endif
--
1.6.4.2
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc
