Forks? (was Re: Tight VNC)

Andrew van der Stock ajv "at"
Sat, 25 Aug 2001 01:54:24 +0000

I've got some changes I'd like to see incorporated into the 5.0 protocol
that Tristan et al are working on. I've got a Word document that I've been
working on for the beginning of the 5.0 auth process, heavily influenced by
the work that the secsh working group are doing, including the adoption of
bi-directional channels to classify traffic*. But I need more feedback from
the AT&T guys as to their direction, and I wouldn't mind seeing even a rough
draft. Once my initial protocol exchange is worked out, I'll be putting up a
draft at my web site for the vnc-sec-l to have a go over and try to
challenge. Security only comes through extensive and open peer review by
both qualified and other interested parties (ie just because you know crypto
doesn't mean you're good at thinking like a fraudster does or understand the
challenges of platform security (ie if your cryptographically secure keys
are obtainable by attacking the platform, they will be, so mitigating the
loss of those keys is vital).

But after 5.0 comes out, I'd like to see the VNC protocol go down the IETF
"Informational" standardization path in the application working group. The
changes I have in mind are security related, and as such require the input
of a vast number of qualified security eyeballs (see all the ssh 1 and 2
problems coming out of the woodwork now that the secsh WG is giving the ssh
2 protocol a good ol' case of GBH after a decent amount of peer review?).

There are other alternatives, but since there are at least three server
(re-)implementations that I know of that do not share history with the ORL
source code base, and heaps of client (re-)implementations, having a true
standard to code to, rather than just a couple of PDF files would be nice.

Anyway, forking code bases is not necessarily bad. Different products for
different needs works okay (ie Palm code base has different aims to a
Windows code base (simple features, small and very efficient code size,
extreme compression needs vs feature rich, object size doesn't really matter
, speed of display is important). As long as everyone moves to the 5.0
protocol quickly my security concerns will be assuaged.


* this would allow the creation of audio, file operations, printer, serial
ports, etc.

----- Original Message -----
From: "W. Brian Blevins" <brian.blevins "at">
To: "ATT Email List" <vnc-list "at">
Sent: Friday, August 24, 2001 11:27 PM
Subject: Re: Forks? (was Re: Tight VNC)

> Illtud and Freddy,
> > Date: Thu, 23 Aug 2001 17:44:21 +0100
> > From: Illtud Daniel <illtud.daniel "at">
> > Subject: Forks? (was Re: Tight VNC)
> >
> > Freddy Jensen wrote:
> >
> > > I have been following some of the email exchange
> > > reg. TightVNC, and I am curious about whether it
> > > will eventually be incorporated into the main
> > > codebase that is maintained at att?
> >
> > Me too! Seems to me that what with Tridia/Tight/AT&T versions
> > all forking off in different directions (somebody correct me
> > if I'm wrong & there's plans to merge diffs or patches) that
> > there's an overall loss to the user community as a whole. One
> > of the problems (I guess) is that what would traditionally be
> > compile-time options (under *ix) don't really work so well
> > when so many of the platforms VNC is available for aren't
> > platforms where people are used to compiling stuff <cough>
> > doze<cough> and so the project forks rather than grows. Pity.
> >
> > Is it possible to pull it all together again?
> We have the Tight 1.2.0 patches from Constantin and will be
> integrating those into TridiaVNC.
> As far as AT&T integrating the Tight encoding, I doubt that
> will happen.  They seem to have come to the conclusion that
> hextile achieves a sort of optimum for CPU usage versus
> level of compression.  Of course, a brief comment from
> someone at AT&T would be much preferrable to my musings.
> Then there is the whole RFB 4.0 and 5.0 work that is going
> on.  I'm beginning to wonder if we will ever see source code
> or documentation on that work.  Again, any comments from
> AT&T would be much appreciated.
> --
> Brian
> --------------------------------------------------------------------------
> TridiaVNC, the cross-platform, open source, remote control solution.
>   and
> ---------------------------------------------------------------------
> To unsubscribe, send a message with the line: unsubscribe vnc-list
> to majordomo "at"
> See also:
> ---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: