Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: > David Somers wrote: >> I may be convinced that being able to proxy to a different destination >> port might be useful... but are there practical reasons to having a cvsnt >> server bind to a port other than its official IANA registered one? > > Probably not (maybe the corner case of running two servers on the same > machine, but that's rare). People do it though... Its sometimes amazing what people do do. >> I'm less convinced that being able to support other protocols is >> necessary. If you want to use a secure connection and your brain dead >> client app only supports pserver or its too much grief to get it to do >> otherwise, then cvssproxy is a lightweight solution that works. It may be >> tempting to have the proxy switch from pserver to sspi, but I think there >> are practical and security implications against it. Comments for and >> against welcome. > > Well the proxy isn't only for security purposes... running sspi > (possibly kerberos encrypted) across a LAN is easier if there's a way to > get all the clients to support it. I'm not too keen on SSPI through a proxy since there could be a security loophole... but I guess it just depends how paranoid and security conscientious you want/need to be. (Probably best to talk about loopholes offline.) > pserver is a bad idea in almost all > cases. The exception, of course, being anonymous access, for which its ideal. > extnt does this, but people aren't used to using ext protocols so they > have trouble configuring it. It's easier to say 'use > :pserver:. at localhost:/cvs.server.org/root' rather than talking them > through configuring their client to talk :ext: in the right way (which > varies from application to application). Hence the ides of the proxy... Sure... then problem then shifts to getting the proxy up and configured... but it should be easier than mucking around with ext. >> When a proxy doesn't follow the KISS method its more inclined to break >> :-) > > OTOH when cvsapi is on the system the proxy is actually simpler if it's > using it, since it's about 3 calls to load a protocol and use it, rather > than going through all the SSL initialisation yourself, parsing the > protocol, etc. SSL initialization isn't that bad... and parsing the protocol is almost non-existant (just the stuff between the BEGIN AUTH... and END AUTH... needs to be handled)... everything else is just blind forwarding. > The opposite is true if it isn't on the system of course.. hence there's > plenty of space for both ideas. Yep. I intend to keep cvssproxy will be nice, simple, and dependent free. Plus it menas that cvssproxy can be used on systems that don't have cvsnt to talk sserver easily. > I'll probably write my own anyway, since it's a good enough idea & > should be nice and quick. "nice and quick" ... that's tempting fate that is. > I would say update the wiki with a link but > I'm considering replacing that over the weekend (what with I haven't > decided - phpnuke looks like a nice idea if I can find a theme that > doesn't suck.. puts the release (and other) announcements on the front > page where they should be) Ta for the heads-up re wiki replacement... I'll hold up with updates until the dust settles... I guess the accounts/passwords will get wiped again. One day packages will come with default themes that don't suck. I guess its hard to know what to replace the wiki with... there are a lot of different systems out there, all with their good and bad points. David