On Wed, Nov 10, 2010 at 01:24:35PM +0100, Guillaume Destuynder wrote: > No difference for me, I did as recommended on the IRC channel. I can put > it directly there, too. If there's already a patch for this however I > don't mind if it's used instead, in fact, it would be great too.
My implemention has it's origins in RealVNC 4 (http://www.auto.tuwien.ac.at/~mkoegler/vnc/tlsvnc.tgz - win+unix implementation). If you need an implementation, you can take parts from there or any of my various ports to other VNC implementation. > That's for being mostly coherent with the defaults. The way VNC handle > them is not really making this clear. > If you do ./vncviewer -h and you get 'cafile default = ""' you would > expect that it loads nothing. > You would have to dynamically parse the home path just for this option > to show the real default path, which is not very nice either. The ~ is > not parsed by the shell unfortunately in this case, hence parsing it in VNC. > Anyway, it's a bit of a hack (since using ~ you don't need to resolve > the path to display), it can be replaced by an empty default and > silently load the default certificates anyway (actually I also did that > in another patch), it's just not very coherent to me. The best thing would be to change the default value of cafile at the startup of the program to $HOME/.... . The current implementation only allows fixed values as default. I hit a similar problem while there was only one security type parameter for viewer and server. My approch was "[PATCH 02/13] Allow changing the default value of string parameters" from 17.Jul.2010 in the tigervnc-devel mailing list archiv. Changing the default value at program startup is in my option better, than interpreting a value in unexpected ways. > 4) > >> + if ((CSecurityTLS::ctd)->getCertificateReply(certinfo)) { > >> + free(certinfo); > >> + exit(1); > > > > I would throw an AuthFailureException here. > I also asked this question in IRC and how they'd like it best, and it > ended up being exit. The exception would display a generic dialog box in > the client, so it would need a custom exception that is ignored by the > client (or feel ok with having yet another dialog telling you that there > was an exception). > > I don't mind with either solution, actually I don't like the exit from > this part of the code too much. I don't see any issue with an message box for an authentification failure, which claims that the authentification has failed, because there is a problem with (processing) the certificate. 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
