We had one-- the Tight Security Extension. :) I signed off on removing it before I fully understood the ramifications.
It's not an immediately critical issue. I mainly wanted to get GnuTLS up and running so I could get it in the hands of users and figure out its place in the universe. The user/password auth will become an issue as soon as I am ready to port over the rest of the TurboVNC authentication extensions, which may not be for a while. User/password auth is of limited or no use without the other extensions. On 2/10/11 3:27 AM, 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. > > Rgds ------------------------------------------------------------------------------ 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
