OpenBSD Project Will Release OpenCVS

thequbemaster writes "The OpenBSD project, responsible for OpenSSH, OpenBGPD, and OpenNTPD, has created OpenCVS, a BSD licensed implementation of CVS client and server. From the site: 'It aims to be as compatible as possible with other CVS implementations, except when particular features reduce the overall security of the system. The OpenCVS project was started after discussions regarding the latest GNU CVS vulnerabilities that came out. Although CVS is widely used, its development has been mostly stagnant in the last years and many security issues have popped up, both in the implementation and in the mechanisms.' No releases are available yet. The README in the OpenCVS CVS repository states that the server is not ready yet, but looks like the client is usable." Update: 12/15 20:18 GMT by T : This project was mentioned briefly the other day, too.

Re:We need a new one?

[MassacrE]

"Any remaining problems"?

You obviously are unfamiliar with the CVS dungpile, err.. codebase. For instance, there is no access provider mechanism - they copied and pasted the code from the filesystem tree to make the pserver tree, then nobody thought "hey, maybe this will be a maintainability problem later?"

There is also no application-level interface to CVS. CVS tools typically use regexp or other parsing techniques to invoke the CVS command-line and parse its contents.

If this causes a slower transition to Subversion, it will be because people don't need to run away from the existing CVS implementation screaming anymore. A good implementation of CVS will put the emphasis of subversion right where it should be - adding compelling features which will convince people to move to it.

As far as 'less interoperability between operating systems' is concerned, I do not see why this would be restricted to BSD systems, any more than openssh was.

Re:subversion?

[TheRaven64]

Because a lot of existing infrastructure still uses CVS? In the long term, transitioning this to SVN is a good idea, and I certainly wouldn't recommend that a new project use CVS. In the mean time, however, I think the OpenBSD people feel that it would be nice to have a CVS implementation that was secure and maintainable.

Re:What is wrong with subversion?

[Phred T. Magnificent]

Damn, where to start? In no particular order:

• Subversion uses too damn much disk space, particularly on the client (not that it's good on the server, either, but when the client is an older laptop with a 9 GB hard drive, you really notice the problem)
• Subversion is slow
• The server-side database is too easily and far too frequently corrupted or left locked by an aborted client request, resulting in ridiculous slowdown on the client side and increased administrative overhead on the server side
• Most Subversion installations are configured to work over HTTP (only). This provides all kinds of nice anti-benefits, like:
  • Eliminating key-based SSH authentication and replacing it with weak password-based HTTP "basic" authentication
  • Replacing a nice, encrypted SSH transport with plain-text HTTP
  • Making it so that in order to use Subversion over an SSH tunnel, you first have to shut down your local Apache server, modify /etc/hosts and set up the tunnel as root, because, of course, a non-root user can't tunnel port 80

The list goes on and on and on, but I'm not interested in continuing it just now. Subversion hasn't managed yet to be the worst version control system I've ever seen: that title is still held by PVCS on Windows 3.1, circa 1995. It's getting to be a close race, though.

Lots of reasons...

[emil]

I am not a fanatic about BSD vs. GPL, but let me count the ways...

1. Anything under BSD license is much more free than GPL free software. Hey, it doesn't change my life much, but there are a lot of people who care about this. More BSD free software is good for everybody.
2. Is it your right to ask OpenBSD developers to GPL their code, when they would prefer to apply a BSD license to it? It certainly isn't mine.
3. It is unlikely that the current CVS uses strlcpy/strlcat. Would retrofitting this functionality be accepted by the CVS people, especially as the GNU libc people have already rejected it? (Boy, that was a great step forward in security there.)

OpenBSD has been slowly stripping/replacing GPL software wherever they can. Recent fatalities include gzip and gawk. It's their distribution, and they can do what they want.

But I for one am glad for OpenBSD. It fits me like a glove. I just wish that Microsoft couldn't copy so much of it.

Re:Development has stagnated?

[Saeger]

Funny coincidence, but today I recieved a message from the Mambo CMS devs asking for community input on switching from CVS to Subversion:

Greetings,

We don't do this often, but it is time for a major decision to be made; and we need your input.

With the migration of MamboForge to the new server, we have the opportunity to change the source code management back-end from cvs to subversion.

Which one do you prefer? You can place your vote on the forums at:

http://forum.mamboserver.com/showthread.php ?t=24861

Regards,

The MamboForge Administration Team

The current poll results favor switching to Subversion by a wide margin.

More power to them...

[psykocrime]

I personally think it's something of a waste to write yet another replacement for CVS, but if they feel they need it, then great. It's open-source, it's volunteer, so nobody has any business telling these people *not* to write OpenCVS.

That said, I (and many others) consider Subversion to be the logical successor to CVS, and it seems to me that any effort spent on revision control would be better spent contributing to Subversion (or Arch maybe) instead of writing yet another version of something that's essentially obsolete.

OTOH, if they have major disagreements with the fundamental architecture of Subversion (and I understand that some people do) then maybe it would be better to just start from scratch, and design their own vision of an ideal revision control system?

Either way, it probably means more quality open source code, and in the long run, everybody ultimately benefits.

Re:We need a new one?

[Azul]

You know, this is precissely how OpenBSD was born. Theo de Raadt was contributing to NetBSD until the NetBSD core decided to remove his write privileges from its sources. Theo, upset, decided to fork and start OpenBSD.

Originally, it had nothing to do with security, but rather with "openness" (from Theo's point of view, after he was kicked out). I suppose it would be called SecureBSD had security been the reason Theo started working on it.

You can find out more about this straight from the horse's mouth [theos.com].

So, I suppose, forking established projects due to disagreements such as these is nothing new for the OpenBSD people.

Re:What is wrong with subversion?

[rudedog]

Subversion uses too damn much disk space

So what. Disk space is too cheap to develop to edge cases like your laptop.

Subversion is slow

Because it's doing a lot more things than CVS ever did. Those things are useful.

The server-side database is too easily and far too frequently corrupted or left locked

I rarely run into locked databases (on the scale of only 1 or 2 a year) and I have never seen database corruption.

Most Subversion installations are configured to work over HTTP (only).

And how is it Subversion's fault that admins don't set the installation up to use a more secure transport. We use subversion over https with a self-signed certificate. The weak point in that chain is not with subversion, it's with the local machine, and if the local machine is compromised, both subversion/https and cvs/ssh are both equally vulnerable.

The list goes on and on and on, but I'm not interested in continuing it just now

In other words, I can't think of anything other than "it won't fit on my 9GB disk", and "some people don't set it up securely".

Lamer.

Re:What is wrong with subversion?

[mirabilos]

Try SSH connection multiplexing with CVS, and
the slowest part - the authentication phase -
is not repeated. Works really really good.