Slashdot Mirror
New BSD licensed CVS replacement for OpenBSD
Jeferey Bakins writes "In an effort, by Jean-Francois Brousseau (jfb@openbsd.org), to rid the OpenBSD CVS tree of GPL'ed licensed code, OpenCVS is now officially part of the OpenBSD project.
For more details, see the OpenCVS homepage;
http://www.openbsd.org/opencvs/"
do we really need a CVS clone, where the only difference is the license?
When the "we" is OpenBSD then the answer is yes.
If you are not part of that "we" then the question is pointless.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
It is not a debate.
"do what thou wilt" is the OpenBSD creed and the GPL is incompatible with that, what's your problem ?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
There's no silver bullet for licences either. The OpenBSDers want their system licenced under their rules, and more power to them. They have to remove all GPL code to do this beacuse the GPL is a more or less all or nothing free software licence.
It's got nothing to do with evangelism, and all to do with practicality. You can't have bits and pieces of code GPLed and some not.
Other licences are more flexible, but are less precise. I'll still be using the GPL for most of the code I write, because I want as many people as possible to use it, and be fully secure in doing so.
May the Maths Be with you!
Then is Open BSD going to stop using GCC ? I mean, GCC is GPL so it is using GPL software to create their system, right ?
UPS Sucks
Read again...
.-) ) to rewrite it. Also, understandable code makes it easier to find a fix non-security bugs (but we like to look at all bugs, as potentially exploitable ones .-)).
/. account)...
While CVS have been a functional tool in simple use, it has quite some drawbacks. Everyone who has been in the CVS guts (believe me, I have), knows that it is essentially write-only code.
It is quite buggy, albeit the bugs are in corner-cases, not seldom noticed by people not using CVS massively. The CVS maintainers have been unwilling to accept bug reports (it may be a matter of opinion: "it's not a bug, it's a feature" has been heard). OpenBSD have had several local changes to cvs over the years.
However, for the reason stated above (write-only code), we cannot trust the code enough. It has been one of the weakest spots of our system securitywise. CVS is also a network service, as such, it can put systems into potential risk, like
all network services. We want to be able to put greater trust into this service. The people who thinks this is just license masturbation are wrong. It is nice to be able to free code, but the important thing is to secure it. GCC is not a network service. The GPL is not reason enough for us (yet
Niklas Hallqvist (I don't care enough to create a
There is a lot more to this than the license, though the license alone would be more than sufficient to justify doing it. While true, CVS is typically a development tool, that is HARDLY the limit of its abilities. What if you want to use a modified CVS to track configuration changes in a non-open source application? Oops! Can't do that with GPL'd CVS.
:). Then there is just plain simple security: nothing stops any person who has CVS access from being able to go in and directly edit the CVS repository files files OUTSIDE the CVS system, leading to untracked changes in the tree.
:-)
CVS development has basicly stalled for quite some time. It has reached "good enough" state -- obviously, considering the number of projects that live off of it -- but there are still issues. Check the OpenBSD CVS Commit logs, search for "cvs sucks" and other such non-positive reviews of CVS's operation.
There are also the relative primativeness of some aspects of CVS and its access rights. If you have access to the CVS repository, you can do anything with it... What if I'm not qualified to work in certain trees? What if I fat-finger an scp operation and upload a huge set of files into the CVS directory (no, I *don't* want to talk about it, but it's not a hypothetical concern!
And that's hardly all the complaints... If you think "license" is the only difference, you obviously didn't read the goals page very carefully (or believed the one line summary
I think the article summary is somewhat misleading, the front page of the project claims that OpenCVS is a result of the ongoing security vulnerabilities in the existing CVS project, which has grown stagnant:
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.
Of course, I'm not going to be stupid enough to deny that there is a great probablity that another unwritten motivating factor was to use a non-GPL licensed piece of software. But, I think time has proven that while OpenBSD may not be a very useable distribution from a common desktop end-user standpoint, a lot of very good portable, secure code has come out of the project. Since I have to continue to run CVS servers for some of the projects I host I look forward to a secure portable CVS server that I can be more confident in.
the point of opencvs isn't to randomly replace GPL'd code, but to provide a different implementation, that is free of bugs and security issues. he's also working on other features to make cvs server better, and more secure.
Umm. No. That's not what it's about at all. Lets correct the mistakes now, shall we?
1) There was no OpenCVS until the OpenBSD project noticed some major security vulnerabilities posted to bugtraq in GNU CVS.
2) The reason why OpenCVS was written was to provide a more secure client/server package than what the [now stagnant] GNU CVS project is currently providing. It has nothing to do with GPL vs BSD, infact the OpenBSD project is all about what RMS calls "free software".
So basically the Slashdot editors posted a troll to the front page. Beautiful.
OpenBSD will stop using GCC when the Tendra Project has reached a satisfactory level of maturity. The OpenBSD team work under the premise that GPLed items are 'free enough for them' until a replacement can be found, just like Linus works under the same premise (see Bitkeeper).
You know, some people don't care for software that is emcumbered by the GPL and it is perfectly reasonable to write a replacement for such software. Just because you don't agree doesn't make it wrong.
The thing that amuses me about this post is that someone probably said this exact thing way back in the 1980s when GNU put together the project to write their own c compiler, unix replacement etc. When will people understand that some people view the GPL in the same manner as those GPL evangelists view commercial licenses - not free enough. Ideology is great, but you have to realise that everyones ideological views are the same - an opinion, and yours may not be the same as mine.
Let me know when they've finished with their GCC, Gnome, and KDE replacements. I'm looking forward to trying them out in 2012.
Judging by this commment I'm guessing you haven't used any BSD variant. The idea isn't to reimplement EVERY piece of GPLed code, only the stuff in the BASE SYSTEM. It's hard for many Linux users to make that distinction, but in BSD you have the base operating system (that's more than the kernel) and the add on software.
Would you be happy using Linux if it had random things that had proprietary licences in it? Of course not. By the same token BSD is about being free via the BSD licence, it's really a snag when you have a mix of tools using BSD and GPL licences.
I don't see stuff like GCC going away, but GCC isn't neccesary for a functioning system so it can be torn out if someone doesn't need it. Most of the base system has GNU utilities in odd spots (tar was recently replaced in FreeBSD for instance). When all of this is said and done you know that the base system is BSD, and the rest of the software is whatever you stack on top of it - no confusion as to what is where.
Here's where I step in with a favorite URL - http://kerneltrap.org/node/view/4126 - wherein Linus himself points out that GCC 3.x is a generally worse C compiler, with some advantages in C++ compiling being its only real saving throws.
While I can't honestly say BSD projects haven't come under the same kind of problems (FreeBSD 5, for instance, which at least right now isn't a pretty sight), the tendancy is not to replace perfectly fine systems (like gcc 2.95's essential core, which was fast and light) with monstrosities (gcc 3.x). If something new is to be implemented, it has to be Right in design and in practice. If a BSD project wrote a compiler, it would be free, light, very UNIXy (functional, not kitschy), and few people would care because it's not GPL and anything non-GPL must be inferior, right? Some people...
Sam ty sig.
If the same class of people are doing opencvs then should we assume that the only safe environment to run opencvs will be OpenBSD, until otherwise proven?
The "class of people" responsible for the bug in portable OpenSSH was me and nobody else - so please don't impugne the other OpenBSD developers.
The fact that the 3.7.1 hole was not exploitable on OpenBSD was due to the fact that the bug related to PAM authentication, which OpenBSD doesn't use (for good reason).
BTW, the bug was a logic error that could have been made in any language, so the standard Slashdolt cry of "C is insecure, use XXX" wouldn't have saved you.
1) Poorly-specified - there are several ambuiguities in the spec, some with security implications if you get it wrong.
2) Implementation differences between Linux-PAM, Sun PAM and OpenPAM - as a direct result of (1) above.
3) Useless broken API which is completely blocking (i.e it prompts for an expects to receive the password/response in a single function call) - making is near-useless for a network application without major trickery
4) Broken design that requires loadable modules which are encouraged by the API to pass opaque data behind the back of the calling application
5) Total lack of separation between policy and mechanism - users are expected to configure policy by specifying which loadable modues are loaded using a silly and restrictive grammar.
6) Zero standardisation for modules or their arguments. As a result, everyone implements things a little bit differently.
Those are just the ones off the top of my head.
1: I explained this in another post, you must have missed it. The BSDs can have sources fetched via CVS (NetBSD recommends this way, rightly so), and having it in the base package makes this infinitely more convenient than having to install the gargantuan cvsup port or poking around for up-to-date-enough source tarballs once daily. Given the relatively small footprint of the CVS client, this convenience is well worth it.
2: They don't have 'too much human resources', you're thinking of Linux. OpenBSD has clear goals and, yes, are motivated to achieve these goals. Security and freedom are goals; this project helps both. The BSDs don't "struggle hard" with manpower, they have as many developers as are needed; everything worth doing gets done. And having less developers is often better for coordination, which is why BSD code bases continue to be consistent and robust.
Sam ty sig.