FileTransfer in TurboVNC 2.1

[amitkumars1985]

Do we have feature of file transfer in TurboVNC ?
Copy paste of text between host and client seems to work but file transfer doesn't work.

VNC version :- TurboVNC 2.1

[dcommander]

Referring to:
https://sourceforge.net/p/turbovnc/mailman/message/35814701/

that feature is a relic of our TightVNC 1.3.x heritage. The file transfer feature only exists in our Windows native viewer, it only works with the legacy TightVNC Windows server (it never worked with the Linux/Unix server, even in TightVNC 1.3.x), and it doesn't work with modern Windows VNC servers that support file transfer (TightVNC 2.x and UltraVNC.) Very few remote desktop/remote display products these days support file transfer, because it represents a security risk, and there are more effective ways of doing it that don't involve the RFB protocol (WinSCP, for instance.)

Upgrading the file transfer protocol in our Windows viewer to support TightVNC 2.x and UltraVNC servers would probably be relatively simple (I assume they are just using a newer version of the protocol than we are.) Adding file transfer support for our Un*x server would be less simple. For security reasons, I would want to ensure that file transfers could only be performed with TLS encryption or SSH. Otherwise, it would be possible to send potentially sensitive information over an unencrypted channel. Also, I'd have to ensure that file transfer could be disabled system-wide in the TurboVNC security configuration file. The TLS requirement would mean that I'd either need to add TLS support to the Windows native viewer (see #8) or add file transfer support to the Java viewer, as well as adding file transfer support to the server.

That starts to resemble a significant undertaking, and I would need either funding or a code contribution to make it happen, since file transfer is not a priority for the community or for any of my current customers (in fact, some of my customers would prefer that the feature not exist, because of the security risk it represents.) There is basically no advantage to doing RFB file transfers over SSH, because you can already find many graphical tools for accomplishing the same thing. The only real advantage would be the ability to transfer files without SSH, but that's not really an advantage. SysAdmins can easily open up SCP or SFTP file transfers for their users without opening up the ability to log into an interactive SSH shell, and if I were a SysAdmin, that is what I would prefer to do. SCP and SFTP receive a great deal of attention from security experts and are thus always going to be more secure than RFB file transfers.

I am not saying "no" to this yet, but I will say that, in order for it to happen, I need:

• A solid argument for why this feature is necessary-- that is, a workflow that relies on this feature and could not be satisfied any other way. (There is a solid argument for why we should support RFB file transfers to Windows servers but not Un*x servers.)
• Funding for my labor to implement it, or a well-written code contribution

[ddavidebor]

Regarding the interface, are you talking about a separate one or something like drag&drop of files ?

[dcommander]

I don't understand the question.

[ddavidebor]

You wrote extensively on the possible protocol implementations, but assuming a viable way to transfer the files, how would you integrate it with Turbovnc UI from the point of view of the user ?

For example: A separate interface with a file browser, a "folder sharing" like windows rdp client, or a drag&drop like macOS remote and windows rdp client?

[dcommander]

There already is a UI in the Windows native viewer. It's an old-school dual-pane file/directory browser that we inherited from TightVNC 1.3.x. I think part of the confusion is that there are really two discussions taking place here.

Discussion 1:

• Whether to upgrade the existing file transfer feature in the Windows native viewer so it supports the newer RFB file transfer protocol used by TightVNC 2.x and UltraVNC servers (Windows only)

Discussion 2:

• Whether to somehow extend that feature into our own server and into all of our viewers.

I accept that there is some purpose to having a file transfer feature for Windows VNC servers, but since supporting Windows VNC servers isn't the primary goal of TurboVNC, I'm not all that excited about supporting that feature. Upgrading the file transfer protocol in our Windows viewer so it supports UltraVNC and TightVNC 2.x servers would be a non-disruptive move that I would support, but only if someone contributed code or funded my labor to do the upgrade. I am less willing to even consider this feature with regard to Un*x servers, since the argument regarding its utility for such servers is much weaker. About the only argument that could be made in favor of it, with respect to Un*x servers, would be a usability argument. If, somehow, we could implement a drag & drop interface, then an argument could be made that having a drag & drop file transfer feature in TurboVNC would provide value add relative to something like a graphical SCP/SFTP client, but such an interface would be very challenging and expensive to implement. Not something I would do unless it was in the context of a long-term relationship with a financial sponsor.

At the moment, TurboVNC doesn't have a lot of resources to work with. I have only myself and whatever money I can make from funded development and patronage. Unless an organization specifically pays for the development of a feature, then all development on the feature has to either come from the General Fund (200 hours of labor that Santos, my biggest customer, funds every year to keep TurboVNC moving forward) or it has to come out of my own pocket. The General Fund renewed just a couple of months ago, but the project was so far behind that I've already had to use up all 200 hours just to get some traction on TurboVNC 2.2. I will probably end up donating an additional 150-200 hours pro bono just to get that release out the door. So stuff like file transfers, while interesting from an academic point of view, are not really on my radar at the moment.

[dcommander]

The native Windows TurboVNC Viewer is being retired in the next major release of TurboVNC, to be replaced with the Java TurboVNC Viewer with a bundled JRE. The Windows TurboVNC Viewer will be maintained in the 2.2.x branch on a break/fix basis, so the proposed file transfer feature would have to be limited mainly to upgrading the file transfer protocol in the existing Windows TurboVNC Viewer so that it supports TightVNC 2.x and UltraVNC servers. I'm happy to do that with funding (it would probably require something like 8-10 hours of labor-- contact me offline for rates.) In general, however, I doubt that anyone is going to be willing/able to pay for the labor to implement a comprehensive file transfer feature in the Java TurboVNC Viewer and TurboVNC Server, given that (a) such a feature is mainly only useful for Windows VNC servers, which are outside the scope of our project/product, and (b) such a feature represents a security risk in enterprise environments. And given that my only interest in that feature would be purely monetary, I'm closing this issue. Again, I'm happy to spend a day looking at how to upgrade the file transfer protocol in the existing Windows TurboVNC Viewer, but that would cost money. The likelihood that anything else will occur on this front is slim to none.

[markd89]

I support Windows users using Reverse VNC connections (single click) and I'm using Linux on my side. Right now I use the (very old) SSVNC client which supports file transfer through a java app that is launched from the viewer. I'm wondering if the file transfer stuff from SSVNC could be plugged into TurboVNC.

Source code is here, at the bottom of the page:
http://www.karlrunge.com/x11vnc/ssvnc.html

Probably this isn't so simple. It's usually not, but I'm just thinking TVNC is Java and this piece is Java and both share a common ancestor so maybe it's not such a big project. I'm just me, but I can make a donation if it would help :-)

[dcommander]

Unfortunately, the implementation in SSVNC is based on the older (applet-based, pre-Swing) Java VNC code base, so it likely wouldn't integrate into the TurboVNC Viewer without some serious refactoring. The cost of that labor is likely to exceed what any one individual would be willing/able to fund (even if someone else does the work and their code is relatively well-written, it still takes a lot of effort to clean up, test, and debug any outside code contributions.) For my purposes, I just don't care about this feature, since it wouldn't benefit our VNC server. Thus, my sole interest in it would be purely monetary, and I'm not even sure if it makes sense in that context, given that it would introduce a viewer feature that isn't supported in our server. That seems like a recipe for end user confusion and poorly-tested code. It might make more sense to start a completely separate OSS project that does nothing but implement a client for RFB file transfers, so you could use that software in addition to the TurboVNC Viewer or another VNC viewer. In order for this to make sense in the TurboVNC Viewer, it would really need to be supported in our server as well, and I don't see much of a path forward for that.

[markd89]

@dcommander thanks for your well thought out response. Unfortunately, you make sense.

Thanks again and thanks for the TurboVNC project :-)