This is good work, but I'll be 100% honest-- after digging myself into a deep pit of GnuTLS Hell this week, the thought of introducing yet another dependency on yet another security library makes me cringe. Is libssh really necessary? I've never observed the port conflicts you're talking about. The -via option always seems to "just work" for me.
You should not take this in any way as an indictment against your good work. It's just that, IMHO, TigerVNC is starting to become unwieldy as a code base. There are too many permutations-- too many X server versions we're trying to support, too many optional features that don't get thoroughly tested because not everyone can build them, etc. Just getting the code to build in a reproducible and documentable manner with GnuTLS on three platforms was a significant project. I'm not even sure of the utility of GnuTLS, given how poorly it performs, but given that it's tied to our authentication system, I think we're probably stuck with it for now. Taming complexity in an open source project is generally the result of necessity. A feature works well because a critical mass of users need that feature enough to try it out. I'm not convinced yet that GnuTLS session encryption meets that guideline. At the very least, it is already a difficult feature to support on Windows. I've already been down the road of built-in session encryption before-- with VirtualGL. We used to statically link with OpenSSL, because of the same problems we're facing with GnuTLS right now-- dynamically linking with it created a binary that was not cross-compatible. Ultimately, I got sick of maintaining my own build of OpenSSL on every platform and pulled the feature out of our default builds. No one missed it. They just started using SSh tunneling. Windows is our most popular client platform, and we need to make sure that it gets treated as a first-class citizen, not as an afterthought. Every new feature must work solidly on it and be buildable by a typical Windows developer. Unfortunately, however, libssh would make that situation worse, not better, as it is a Unix-centric library like GnuTLS is. And it's not as widely-available on Linux platforms as GnuTLS is, meaning that most developers would have to build it from source. TigerVNC is in danger of becoming so complex that only system integrators will dare to touch the code, and that's not a good thing for any of us. IMHO, we really need to do some deep thinking about what we want to be as a project. I would say that, going forward, we either need to figure out a way to reduce our permutations, or we need to consider forking off some of the technologies into separate, independent builds. The Windows server and Java viewer, for instance, would be good candidates for that, as would removing libjpeg-turbo from our source tree and using the upstream builds of that library (that would at least mean that you don't have to have NASM to build TigerVNC.) As Cendio is proposing to move to a unified cross-platform viewer code, I even wonder whether we shouldn't split viewer and server into separate builds. How much of the code will really be shared by both once the viewer is using FLTK? These are topics for deep discussion, and I may be labeled a heretic for even bringing them up. I just worry that our goals are starting to diverge. The new features are being pushed in from Fedora, which means that they are typically hard to support on older Linux platforms or Windows or Mac, and I feel like I'm spending more time integrating and less time innovating. I don't want to see us become another X.org. Anyhow, I apologize for using your post as a vehicle for venting about the project direction. Chalk it up to a tragedy of timing. I really appreciate your effort and contribution nonetheless. On 2/10/11 11:26 PM, Eric Stadtherr wrote: > Hi, > > I have completed the code & build changes necessary to utilize libssh > within vncviewer for "-via" SSH connections (instead of starting a > /usr/bin/ssh child process). This solves the issue of two vncviewer > processes trying to start SSH processes bound to the same local port > during startup, and has some nice fringe benefits such as eliminating a > process and a socket when in this tunneling mode. The changes were > relatively straightforward - I was even able to successfully replicate > the "process GUI events when the SSH channel read would block" > methodology with the libssh API. > > In brief, the changes are as follows: > > * Implement a new "SSHChanConn" connection class (derived from > CConn) that establishes the SSH connection and creates a > forwarding channel to the specified VNC server. > * Implemented new RDR stream classes to handle the SSH channel I/O > (SSHChanInStream and SSHChanOutStream). These are derived from the > FdInStream and FdOutStream classes in order to re-use the existing > event processing, buffer management and timing logic. > * Modified configure.ac and Makefile.am files to dynamically > discover the presence of the libssh library in the build > environment, and add define flags and make targets appropriately > * Reworked some of the logic in vncserver.cxx that handled the > "-via" flag, and implement a decision between CConn or SSHChanConn > depending on the presence of that flag. > > > The work isn't 100% complete, since I wanted to ask how you would prefer > some things be handled: > > 1. SSH Authentication - I use the API to discover the authentication > mechanisms supported by the SSH server, and try each in turn until > authentication is successful (key pair, password, > keyboard-interactive, none). I haven't tested the "None" or > "Password" authentication mechanisms, since I don't have access to > an SSH server that is configured for those methods. How do you > want to handle that testing? Are there other auth methods that you > would like to see supported? > 2. Man page - I made the "-via" argument conditionally present based > on the presence/absence of the libssh library during the build. > First, do you agree with that approach? If so, how should the man > page be handled? Can we conditionalize the description of that > argument, or just put a caveat about "only available if built with > libssh" or something along those lines? > 3. Patch submission - I have a .patch file built against the latest > Subversion trunk, but the changes are fairly extensive. Is a > .patch file still appropriate, or would you like to see things a > different way? > > > Thanks! > -Eric > > > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
