Depends on the feature, but a major feature will typically cost thousands of dollars in labor to implement. I can provide more specific estimates offline based on specific feature requests.
On 3/18/17 4:56 PM, Steve Volumetric wrote: > Thank you for your thoughtful response. On security, I see where you're > coming from in the linux-realm, I can't speak to Windows or OS X as I've > nearly entirely cut them out of my life. > If the cookie crumbles in the way you describe regarding security and > java applications, then my biggest nit-pick is having fewer packages > installed and overall having fewer inodes junking up a filesystem. > Ideally, It'd be nice to compile the vncviewer as a static binary, but > that's clearly not super practical at the moment, it'd just be a "nice > to have." The fewer dependencies I need to have on a given system, the > happier I am when it comes to backups, updates and overall management. > Falling squarely into the category of "things that are my problem" is > that my linux distro is little more than the kernel, a basic package > manager which compiles things from source...or compiling things from > source yourself so java isn't exactly at arm's length to me, but it's > ok, I can always find a way to make it work. Luckily in this case, you > managed to find a way to really optimize the hell out of it, and even > over wifi raw lossless vnc-ing is incredibly responsive. When it comes > to funding to make something possible, how much funding is that, generally? > > On Sat, Mar 18, 2017 at 4:13 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > Also, with respect to Java, if you are running a standalone Java > application, then it is no more or less secure than a standalone native > application. The security risks you refer to are primarily related to > running Java in a web browser, which most web browsers don't support > anymore. The Java TurboVNC Viewer still supports an in-browser applet > mode, but even the company who paid for that feature can no longer use > it because of lack of Java plugin support in modern browsers. It really > isn't an issue unless someone absolutely needs a VNC viewer that runs in > their browser window. Otherwise, Java Web Start can easily be used to > launch the TurboVNC Viewer in a "zero-install" capacity, without > requiring any browser plugins, as long as a JVM is installed on the > client machine. I'm also looking into extending noVNC to support the > RFB flow control extensions and other features necessary to make it > perform reasonably on WAN connections. It will never perform very well > on LAN connections, but I'd like to at least make it as fast as > possible, so it can serve as a stopgap for those who previously needed > the in-browser TurboVNC Viewer applet. The long-term solution for an > in-browser VNC viewer is probably WebAssembly, but all of that stuff is > still in a state of flux right now. > > With the exception of risks introduced by improper installation or > configuration, probably the worst-case security risk of a VNC viewer is > that you're using the built-in session encryption feature (VeNCrypt) > with a buggy underlying SSL implementation, which could conceivably (but > not easily) expose you to such exploits as a "man in the middle" attack. > It is conceivable that such an attack might allow the attacked to snoop > your Unix login credentials, if you were authenticating with the server > using those credentials. That's actually an argument in favor of Java, > however, because the underlying SSL implementation that our Java viewer > uses is part of the JVM, and Oracle does a pretty good job of keeping > abreast of any security flaws in it. Producing a cross-platform native > viewer would require that we either link statically with OpenSSL or > GnuTLS (requiring us to keep abreast of any potential security flaws in > those libraries ourselves-- no thanks) or to load OpenSSL on demand like > we do in the server. The latter approach will probably be the approach > I take to implement session encryption in the next-gen cross-platform > native viewer, but that approach is really no more or less secure than > Java. It still relies on someone else-- in this case, the O/S > distributor-- to keep abreast of security bugs in the SSL/TLS libraries. > On Linux, this is really no different than using Java, since the > distribution-supplied OpenJDK implementations will themselves link > against the system-supplied build of GnuTLS or OpenSSL. But Java has a > slight edge, because-- at least on Linux-- you can obtain it from > multiple sources. So if the distribution-supplied JVM has a security > bug that Oracle has fixed, you can install Oracle's version until the > distribution maintainers fix the bug in their implementation. > > The historical reasons behind the hybrid Java/native viewer on Mac and > Linux platforms were primarily monetary. I received funding in the 2012 > timeframe to develop a proof-of-concept Android TurboVNC Viewer, and > since Android is a Java-based platform, the first phase of this involved > improving the Java TurboVNC Viewer so that it had the necessary > underlying features to provide a full-fledged TurboVNC Viewer > experience. Phase 2 would have involved developing a new, > Android-specific GUI. The project was dropped prior to Phase 2, but > since the resulting Java TurboVNC Viewer was much more user-friendly and > feature-rich than the existing Un*x/X11 viewer (which, at the time, was > based on Xt, which required XQuartz on Mac and had the crappiest GUI > imaginable), the Java viewer was phased in as a replacement. In > TurboVNC 1.2, the Java viewer fully replaced the Xt viewer on Mac > platforms and was provided as an option on Linux platforms. With > TurboVNC 2.0, I introduced a new glueware library on Linux that worked > around some underlying Java/X11 interaction issues, which allowed the > Java/native hybrid viewer to fully replace the Xt viewer, so the Xt > viewer was retired in that release. > > I do recognize that, at least on Mac and Windows platforms, a Java > viewer introduces additional install dependencies that may not be > desirable in all cases. Also, our Windows viewer is popular and has > some GUI features that the Java viewer lacks-- another reason to expand > it to other platforms. Fortunately, there is now funding to look into > this, although the feature may not be fully implemented until next year > because it is not the highest priority. > > > On 3/17/17 9:37 PM, Steve Volumetric wrote: > > DRC - thanks for putting all this together, by the way. I'm a big fan. > > Unrelated, I gave up on trying to compile the turbovnc viewer from > > source (my linux distro is too weird) and I got up and running off your > > precompiled rpm that I pried apart. You're right - the performance is a > > staggering improvement over TigerVNC even with the java dependency! > > > > On Fri, Mar 17, 2017 at 9:34 PM, DRC <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > The Windows viewer has a pure C++ version, but other platforms > require > > Java at the moment. Why is that a limitation? It's as fast as our > > native viewer and considerably faster than TigerVNC's native viewer > on > > Mac platforms. I am looking at a cross-platform native viewer in > the > > long term, probably based on our Windows code but ported to some > > cross-platform toolkit like GTK. For now, however, Mac and Linux > > require Java. > > > > On 3/17/17 6:22 PM, Steve Volumetric wrote: > > > I'm hoping the viewer isn't completely java dependent, though so > far > > > that's the only way I've been able to build it. > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > <https://lists.sourceforge.net/lists/listinfo/turbovnc-users> > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
