No. The reason to use "octet" is because you want to sound like an IETF RFC, because that makes you sound more authoritative or because it makes your boyfriend horny.
He loves the Israelites more than he loves the Egyptians.
I hope I never experience the kind of "love" that is expressed in slaughtering millions of children.
Are you saying an omnipotent, omniscient god couldn't think of a better way out than just killing many thousands or millions of babies? For shame. Why not kill the Egyptian leaders, who bore more responsibility? Why not strike down Egyptians when they tried to harm Israelites? Why not teleport all the Israelites away? Why not turn all the Egyptian weapons into silly-putty and give the Israelites rayguns?
Humans have fought major wars without descending to killing a person from every single house in a country. However worthy the cause, such gratuituous bloodshed is never justified or militarily necessary. Those who do that we call genocidal tyrants.
"Every boy that is born you must throw into the Nile, but let every girl live."
"He did it first!" might work for five-year-olds, but it is not credible for adults, let alone deities.
By definition, an omnipotent god could free his people without wallowing in babies' blood. As I see it, there are three main possibilities:
1. The book is simply a collection of myths. Since it's fiction, it is not self-consistent: at times god is loving; at other times psychopathic. Etc.
2. God exists and is powerful, but really likes killing. This contradicts a lot of other Christian doctrine, is a pretty unpleasant idea, and in any case barely substantiated. If I had to believe in bloodthirsty supernatural entities, I think vampires have better style.
3. You redefine all the words so as to make them meaningful: "he 'loved' the egyptian babies so he had to kill them", etc. Or you say "god is a mystery". This is mere sophistry. You can "prove" any argument by redefining language.
I came to feel that way about it by reading regular, unannotated bibles long before I ever discovered the SAB. I find SAB a handy reference to absurdities, but I don't need it to tell me they're absurd.
I hope I am never going to change my point of view that rape, murder, etc are wrong, and that writers who praise them are evil. If I want poetry from a whackjob I think I'll choose Nietzsche; he's a better writer.
Nevertheless there are some very laudable and beautiful parts in the bible. If you eliminated perhaps 80 or 90% you might have an excellent book. And of course, though they never admit it, this is what most decent Christians do: they read and quote the good bits, and skip over all the horrible accounts of nasty brutal tribes and their Small God.
OK, so let's try one case: slaughter of all the firstborn children of Egypt in Exodus. I think it is very cruel to kill all those children. In modern times it would be a crime against humanity. If you want to explain how it is the action of a loving universal god, or indeed of anything but a psychopath, then I would be fascinated to hear. I am prepared to change my mind if your argument is good.
One is to show that, even accepting your presuppositions, the argument is inconsistent. For example, we could make a case that the axiom that there is an omipotent loving god is inconsistent with all the needless suffering in the world, unless we twist the word "loving" until it loses all meaning. (What loving parent would have their child born with terminal cancer if they could control it?) A great deal of "theology" tries to prove whether the system is self-consistent, or to tweak it so it is.
A different argument is to say that although your system may or may not be consistent, it is not useful. God can be excised with Occam's razor.
One can posit any number of arbitrary invisible beings: god, buddha, great pumpkin, eris, etc. It is always possible to make up contrived theories which are not disprovable and that are self-consistent. That does not make the theories particularly worthwile; it just gets them through the first gate.
One form of Occam's razor is that the theory which is simplest and requires the least assumptions while still explaining the observed facts is more likely to be true and useful.
To "earn" your enormous assumption of supernatural beings, your theory needs to be able to explain observations which a simpler theory either gets wrong or cannot explain. (Insert standard case of newtonian->relativistic physics.) Religious attempts to claim explanations of particular phenomena have consistently being knocked over by advancing science.
One that lingers like a bad smell is "where did the first life come from?" It is not sufficient for religion to just say "God did it"; science might as well say "it just happened." To claim explanatory power you need to provide some kind of *explanation*: did god move atoms around using tractor beams, or did a bunny rabit appear ex nihilo and if so how, etc.
How come everytime we fuck up paradise, it's proof that God doesn't exist or doesn't love us?
Yeah, God gave us the freedom not to cause earthquakes or plagues. If only those people in the 10th century had used their god-given intelligence to invent antibiotics, they wouldn't have suffered the Black Death! Children get leukemia because they're sinners!
Uh huh.
Did you ever see the Onion story: "God answer's sick child's prayer. 'No', says God."
God does not show his compassion by not allowing us to show ours.
On the contrary: the Giant Pumpkin shows His twisted sense of humor by allowing us to believe in God.
Oh, it's OK to rape, mutilate, enslave, murder as long as you're doing it to whole cities, not to particular named women? OK. Yeah, when you put it like that it obviously testifies to a loving god.
The very most you can charge against SAB here is that it's just misfiled under Women rather than Genocide.
The SAB points out contradictions, foolishness and outright evil in the bible. One reasonable response to this is to say, "well, it's just an alegory", or "it's just poetry", or "it just reflects the limited knowledge of the Israelites" when they describe insects with four legs and so on. Fair enough. But let's see people be consistent on that point, and not ever claim that the bible is any more than just ancient mediocre poetry.
If it is supposed to be true, it should not contain contradictions and idiocies. But it does.
If it is supposed to give a defensible moral code, it should not speak approvingly of rape, torture, incest, massacre, etc. But it does.
I suggest you read the svn mailing list threads from a couple of years ago, when the developers realized that insisting on DAV was a major impediment to svn being adopted.
On one hand you're suggesting that people run thttpd and on the other you're complaining about switching to apache2?
I am pointing out that darcs/arch let you use whatever server you want. If you already have Apache, use Apache. If you have no preference and are worried about security, you might want to use something smaller than Apache. If you like SPARK Ada, use a server written in SPARK Ada. You have the choice.
Subversion, on the other hand, to publish over HTTP requires Apache2. And not only do you lose the choice, you also have to migrate to a server which is not yet widely adopted. Any reasonable sysadmin would be concerned by the security implications.
Subversion is capable of running over the local filesystem, just like arch.
Yes, but that's not helpful here. We are trying to publish our source so that anyone can download it. Subversion requires you to run a server: either anonsvn or anoncvs.
They all do pretty much the same things, and have the same security downfalls.
I consider needing to run an additional complex publicly accessible server to be a problem. This is a pretty basic principle of network security. It's not absolutely fatal, but it's pretty bad. Darcs and Arch do not require you to take this risk just to publish source.
Here's another security principle for you: "what's not there, can't break." We are posting on a story about remotely exploitable vulnerabilities in anonymous svn servers. That whole function is not required in Darcs/Arch and will therefore never have a security hole.
Stop trying to claim that distributed operation is more secure because you'd be willing to use a distributed server in a different manner than you'd use subversion or cvs. If you didn't want to run a network service you'd be more secure, but you can do that without 'distributed' versioning systems.
I'm not claiming either of those things. The scenario I describe allows a proper superset of what is possible with cvs/svn as they are used by open source projects.
I think he meant that deeply pipelined machines suffer a worse penalty when they get a cache miss. So it's worth making both L1 and L2 as large and fast as you can. It doesn't directly effect the hit ratio as far as I know.
I think it would be really interesting to work in a place that genuinely and deeply cares about quality. (Or maybe it would be really frustrating. Either way.)
That's bad in general, but there's also a specific legal limitation to it: If the source code is GPL, and the project releases precompiled executables, then they are obliged to provide the exact source code version used for that executable. This is trivially accomplished with CVS, but rsync alone is inadequate.
Wow, fascinating point. I can imagine that some of the well-intentioned sites providing binaries of prereleases could be technically in trouble there.
"Microsoft uses DCERPC, an extension of TCP/IP, as a transport mechanism."
I'm glad they used a standard protocol, though it's a shame it turned out to be a bit of a lame duck. But nevertheless, it is *another* protocol in the sense that nobody would be running it if it weren't for Svn. Therefore, it increases the amount of code that can be attacked.
I wouldn't be surprised if using svn under Apache doubled the amount of code reached by anonymous requests.
Note that now they've given up on getting everyone to install Apache2 and use DAV/SSL, the recommended protocol is svnserve, which was invented from scratch.
It is possible that there's a vulnerability in the patch command, or in the equivalent in darcs or arch that accepts changes from contributors. Such a vulnerability might allow a malicious submitter to take over a developer's machine when they try to read or apply the change.
This is conceptually no different to a vulnerability in a mail client or HTML viewer or any other program that views files read over the network. Those things happen, but they're not generally seen as such a big problem as an attack on a network server, for two reasons: the attack is harder to carry out, and easier to trace.
I'm only likely to even think about applying a changeset from a credible source, whereas anoncvs by definition accepts requests from any IP. If they do attempt an attack then I have a record of where it was sent from, etc.
One fix is that change requests should be easy for a human to read without a special tool. Darcs does this, and Arch and Bitkeeper do not. It's probably pretty unlikely there could be an exploit that would look harmless when viewed by a human. In this case basically the only way Darcs is going to be invoked is when the input has already been vetted by a person.
subversion uses apache, which means you don't have to have a whole new server.
Subversion uses Apache2, which *is* a whole new server from what the majority of people are running these days. Subversion deployed under Apache requires you to run a new DAV module under Apache -- and there has been quite a number of exploitable vulnerabilities in the neon DAV code over the last few years. Publishing a public Subversion repo requires you to run 10,000s of lines of new network-accessible code.
Also, Subversion requires that Apache have filesystem write access to the db files in the repo. So all in all it is a pretty unattractive proposition.
in order to run a version control system you're going to have to have writing somewhere
Writing in Darcs or Arch only occurs over SSH by the one person who owns the archive. There is no increased exposure. Anyone who is reading the anonymous archives can mail me diffs, as before. Now, perhaps they could try to break into my mailserver but they could try that before too.
I don't think your concerns about "more of the system being untrustworthy" reflect an understanding of the way these systems actually work. But if you want to give a proper argument please do.
Let me draw you a picture.
1: Project before using version control: one read-only web server, accessible over ssh, developer has an email account.
2A: After adopting darcs: no increase in exposure. Developer publishes stuff by pushing it onto the web server over SSH, just as they do for the web site. Developer gets patches by email.
2B: Contrariwise, after using CVS or Subversion, in the safest possible way to use them: A new service, of 10000s of lines of C code runs on the public server, accepting connections from arbitrary clients. The service needs to be able to write to files on the server. It is likely that the canonical repository resides on the same machine, so you put your crown jewels on the very machine which just opened up a new potential vulnerability.
Yes, HTTP is a pretty complex protocol. However, you can write extremely simple read-only servers, such as thttpd or publicfile.
Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.
Distribution makes untrusted input problems worse since components of your 'server' can no longer even trust each other.
The version control system doesn't trust the web server, or receive any input from the network.
Systems which are more fixable, or more quickly fixed (which is slightly different) present a real-world advantage.
Discovery of a vulnerability in say CVS or IIS does not mean every installation in the world will be compromised immediately. It means that the clock starts ticking. If a fix is released and applied more quickly, then there is less risk that any given machine will be compromised. Look at Schneier's "exposure envelope" model.
Historically open source has done reasonably well, though not perfectly, at releasing fixes very soon after vulnerabilities become known to the author. Open source projects tend to also be more responsive to reports, which encourages security reporters to do the right thing and report to the authors, knowing that they will get a quick response and proper credit.
There are many reports of proprietary companies sitting on vulnerabilities for more than a year. I have seen Microsoft sit on one for a couple of months. That is an enormous exposure. Being able to fix it yourself may be cold comfort but it's better than having your machines rooted.
It might be more effective to splash it around their torso, but not the cigarette. That way the cigarette won't be doused, but it can ignite the vapor. Obviously you should remove the idiot to a safe distance before doing this.
Just update CVS from FreeBSD whenever they apply the fix. If FreeBSD haven't made a new release yet, then you might want to turn off public access until it's fixed.
I wonder how many virus would be released that will take advantage of these security holes.
I think it's pretty unlikely there will be even one.
The number of machines in the world running public CVS servers must be pretty low: probably hundreds or thousands, but that's tiny compared to the number running Linux or Apache, let alone Windows. A worm that tried to propogate by scanning networks, as most do, would probably fizzle out. I don't think it would be worth the effort to write a virus.
Add to this the fact that CVS servers are probably a bit more diverse in OS/architecture than desktops, and that owners of CVS server probably pay a little more attention to them than does your average desktop user.
Anyone who wants to exploit this hole would be more likely to try to do it by hand against targetted important machines.
Any sane person running anoncvs should have it in a chroot jail, where an attack would cause less damage.
These vulnerabilities are a consequence of an architectural security flaw in both CVS and Subversion: they require an active server that talks a complex protocol to an unauthenticated client.
Whenever you allow an untrusted client to control code running on your server, there is a risk of a compromise.
The distributed version control systems Darcs and Arch show a better way. Read-only access requires only some read-only files published over HTTP. Since most projects already have a web site, this means there is no increase in the network services that need to be offered.
Once those files are downloaded, the anonymous user can get updates, make their own patches, branch -- all the facilities allowed by anonsvn/anoncvs and more.
It's where a variable on the heap gets overwritten:
char *a = malloc(4), *b = malloc(4); strcpy(a, "hello to all my fans in domestic surveillance"); /* kablooey */
The strcpy writes past the end of the allocated buffer. Several things might happen: first, and the best possible outcome is that it writes to an unmapped page and you die immediately with segv. Or it writes over a malloc control structure and a later call to malloc() or free() causes an indirect crash. (Sometimes called a "heap scribble".) Or it might write over some other heap variable, like b in this example.
Which one happens depends on the libc and the allocation pattern, but for any app on any particular system it may be predictable.
The one that is easiest to exploit is writing over another variable, like b. This gives the attack a way to write into a variable they weren't meant to access, which leads in short order to the computer being stretched wide open.
Dr Hos'e may have indulged in the trollish arts in the past, but he does have a point:
how many otherwise great programmers and source control systems gurus cannot post bugfixes to CVS and Subversion codebases thanks to Bitkeeper's EULA
I've received patches from kernel developers for my open source programs. The BK licence makes them give up the right to file CVS or Subversion bug reports, in order to use BK for free.
I don't think CVS or Subversion would suit Linus's style, but maybe Arch or Darcs will in the future.
Slashdot Mirror
No. The reason to use "octet" is because you want to sound like an IETF RFC, because that makes you sound more authoritative or because it makes your boyfriend horny.
octet==byte.
He loves the Israelites more than he loves the Egyptians.
I hope I never experience the kind of "love" that is expressed in slaughtering millions of children.
Are you saying an omnipotent, omniscient god couldn't think of a better way out than just killing many thousands or millions of babies? For shame. Why not kill the Egyptian leaders, who bore more responsibility? Why not strike down Egyptians when they tried to harm Israelites? Why not teleport all the Israelites away? Why not turn all the Egyptian weapons into silly-putty and give the Israelites rayguns?
Humans have fought major wars without descending to killing a person from every single house in a country. However worthy the cause, such gratuituous bloodshed is never justified or militarily necessary. Those who do that we call genocidal tyrants.
"Every boy that is born you must throw into the Nile, but let every girl live."
"He did it first!" might work for five-year-olds, but it is not credible for adults, let alone deities.
By definition, an omnipotent god could free his people without wallowing in babies' blood. As I see it, there are three main possibilities:
1. The book is simply a collection of myths. Since it's fiction, it is not self-consistent: at times god is loving; at other times psychopathic. Etc.
2. God exists and is powerful, but really likes killing. This contradicts a lot of other Christian doctrine, is a pretty unpleasant idea, and in any case barely substantiated. If I had to believe in bloodthirsty supernatural entities, I think vampires have better style.
3. You redefine all the words so as to make them meaningful: "he 'loved' the egyptian babies so he had to kill them", etc. Or you say "god is a mystery". This is mere sophistry. You can "prove" any argument by redefining language.
I came to feel that way about it by reading regular, unannotated bibles long before I ever discovered the SAB. I find SAB a handy reference to absurdities, but I don't need it to tell me they're absurd.
I hope I am never going to change my point of view that rape, murder, etc are wrong, and that writers who praise them are evil. If I want poetry from a whackjob I think I'll choose Nietzsche; he's a better writer.
Nevertheless there are some very laudable and beautiful parts in the bible. If you eliminated perhaps 80 or 90% you might have an excellent book. And of course, though they never admit it, this is what most decent Christians do: they read and quote the good bits, and skip over all the horrible accounts of nasty brutal tribes and their Small God.
OK, so let's try one case: slaughter of all the firstborn children of Egypt in Exodus. I think it is very cruel to kill all those children. In modern times it would be a crime against humanity. If you want to explain how it is the action of a loving universal god, or indeed of anything but a psychopath, then I would be fascinated to hear. I am prepared to change my mind if your argument is good.
There are two ways to answer your argument.
One is to show that, even accepting your presuppositions, the argument is inconsistent. For example, we could make a case that the axiom that there is an omipotent loving god is inconsistent with all the needless suffering in the world, unless we twist the word "loving" until it loses all meaning. (What loving parent would have their child born with terminal cancer if they could control it?) A great deal of "theology" tries to prove whether the system is self-consistent, or to tweak it so it is.
A different argument is to say that although your system may or may not be consistent, it is not useful. God can be excised with Occam's razor.
One can posit any number of arbitrary invisible beings: god, buddha, great pumpkin, eris, etc. It is always possible to make up contrived theories which are not disprovable and that are self-consistent. That does not make the theories particularly worthwile; it just gets them through the first gate.
One form of Occam's razor is that the theory which is simplest and requires the least assumptions while still explaining the observed facts is more likely to be true and useful.
To "earn" your enormous assumption of supernatural beings, your theory needs to be able to explain observations which a simpler theory either gets wrong or cannot explain. (Insert standard case of newtonian->relativistic physics.) Religious attempts to claim explanations of particular phenomena have consistently being knocked over by advancing science.
One that lingers like a bad smell is "where did the first life come from?" It is not sufficient for religion to just say "God did it"; science might as well say "it just happened." To claim explanatory power you need to provide some kind of *explanation*: did god move atoms around using tractor beams, or did a bunny rabit appear ex nihilo and if so how, etc.
How come everytime we fuck up paradise, it's proof that God doesn't exist or doesn't love us?
Yeah, God gave us the freedom not to cause earthquakes or plagues. If only those people in the 10th century had used their god-given intelligence to invent antibiotics, they wouldn't have suffered the Black Death! Children get leukemia because they're sinners!
Uh huh.
Did you ever see the Onion story: "God answer's sick child's prayer. 'No', says God."
God does not show his compassion by not allowing us to show ours.
On the contrary: the Giant Pumpkin shows His twisted sense of humor by allowing us to believe in God.
Oh, it's OK to rape, mutilate, enslave, murder as long as you're doing it to whole cities, not to particular named women? OK. Yeah, when you put it like that it obviously testifies to a loving god.
The very most you can charge against SAB here is that it's just misfiled under Women rather than Genocide.
The SAB points out contradictions, foolishness and outright evil in the bible. One reasonable response to this is to say, "well, it's just an alegory", or "it's just poetry", or "it just reflects the limited knowledge of the Israelites" when they describe insects with four legs and so on. Fair enough. But let's see people be consistent on that point, and not ever claim that the bible is any more than just ancient mediocre poetry.
If it is supposed to be true, it should not contain contradictions and idiocies. But it does.
If it is supposed to give a defensible moral code, it should not speak approvingly of rape, torture, incest, massacre, etc. But it does.
I suggest you read the svn mailing list threads from a couple of years ago, when the developers realized that insisting on DAV was a major impediment to svn being adopted.
Also: why are you such a coward?
On one hand you're suggesting that people run thttpd and on the other you're complaining about switching to apache2?
I am pointing out that darcs/arch let you use whatever server you want. If you already have Apache, use Apache. If you have no preference and are worried about security, you might want to use something smaller than Apache. If you like SPARK Ada, use a server written in SPARK Ada. You have the choice.
Subversion, on the other hand, to publish over HTTP requires Apache2. And not only do you lose the choice, you also have to migrate to a server which is not yet widely adopted. Any reasonable sysadmin would be concerned by the security implications.
Subversion is capable of running over the local filesystem, just like arch.
Yes, but that's not helpful here. We are trying to publish our source so that anyone can download it. Subversion requires you to run a server: either anonsvn or anoncvs.
They all do pretty much the same things, and have the same security downfalls.
I consider needing to run an additional complex publicly accessible server to be a problem. This is a pretty basic principle of network security. It's not absolutely fatal, but it's pretty bad. Darcs and Arch do not require you to take this risk just to publish source.
Here's another security principle for you: "what's not there, can't break." We are posting on a story about remotely exploitable vulnerabilities in anonymous svn servers. That whole function is not required in Darcs/Arch and will therefore never have a security hole.
Stop trying to claim that distributed operation is more secure because you'd be willing to use a distributed server in a different manner than you'd use subversion or cvs. If you didn't want to run a network service you'd be more secure, but you can do that without 'distributed' versioning systems.
I'm not claiming either of those things. The scenario I describe allows a proper superset of what is possible with cvs/svn as they are used by open source projects.
I think he meant that deeply pipelined machines suffer a worse penalty when they get a cache miss. So it's worth making both L1 and L2 as large and fast as you can. It doesn't directly effect the hit ratio as far as I know.
I'm mildly amused that one person could like both Perl and SPARK.
I think it would be really interesting to work in a place that genuinely and deeply cares about quality. (Or maybe it would be really frustrating. Either way.)
Maybe when I get older and more curmudgeonly...
That's bad in general, but there's also a specific legal limitation to it: If the source code is GPL, and the project releases precompiled executables, then they are obliged to provide the exact source code version used for that executable. This is trivially accomplished with CVS, but rsync alone is inadequate.
Wow, fascinating point. I can imagine that some of the well-intentioned sites providing binaries of prereleases could be technically in trouble there.
"Microsoft uses DCERPC, an extension of TCP/IP, as a transport mechanism."
I'm glad they used a standard protocol, though it's a shame it turned out to be a bit of a lame duck. But nevertheless, it is *another* protocol in the sense that nobody would be running it if it weren't for Svn. Therefore, it increases the amount of code that can be attacked.
I wouldn't be surprised if using svn under Apache doubled the amount of code reached by anonymous requests.
Note that now they've given up on getting everyone to install Apache2 and use DAV/SSL, the recommended protocol is svnserve, which was invented from scratch.
It is possible that there's a vulnerability in the patch command, or in the equivalent in darcs or arch that accepts changes from contributors. Such a vulnerability might allow a malicious submitter to take over a developer's machine when they try to read or apply the change.
This is conceptually no different to a vulnerability in a mail client or HTML viewer or any other program that views files read over the network. Those things happen, but they're not generally seen as such a big problem as an attack on a network server, for two reasons: the attack is harder to carry out, and easier to trace.
I'm only likely to even think about applying a changeset from a credible source, whereas anoncvs by definition accepts requests from any IP. If they do attempt an attack then I have a record of where it was sent from, etc.
One fix is that change requests should be easy for a human to read without a special tool. Darcs does this, and Arch and Bitkeeper do not. It's probably pretty unlikely there could be an exploit that would look harmless when viewed by a human. In this case basically the only way Darcs is going to be invoked is when the input has already been vetted by a person.
subversion uses apache, which means you don't have to have a whole new server.
Subversion uses Apache2, which *is* a whole new server from what the majority of people are running these days. Subversion deployed under Apache requires you to run a new DAV module under Apache -- and there has been quite a number of exploitable vulnerabilities in the neon DAV code over the last few years. Publishing a public Subversion repo requires you to run 10,000s of lines of new network-accessible code.
Also, Subversion requires that Apache have filesystem write access to the db files in the repo. So all in all it is a pretty unattractive proposition.
in order to run a version control system you're going to have to have writing somewhere
Writing in Darcs or Arch only occurs over SSH by the one person who owns the archive. There is no increased exposure. Anyone who is reading the anonymous archives can mail me diffs, as before. Now, perhaps they could try to break into my mailserver but they could try that before too.
I don't think your concerns about "more of the system being untrustworthy" reflect an understanding of the way these systems actually work. But if you want to give a proper argument please do.
Let me draw you a picture.
1: Project before using version control: one read-only web server, accessible over ssh, developer has an email account.
2A: After adopting darcs: no increase in exposure. Developer publishes stuff by pushing it onto the web server over SSH, just as they do for the web site. Developer gets patches by email.
2B: Contrariwise, after using CVS or Subversion, in the safest possible way to use them: A new service, of 10000s of lines of C code runs on the public server, accepting connections from arbitrary clients. The service needs to be able to write to files on the server. It is likely that the canonical repository resides on the same machine, so you put your crown jewels on the very machine which just opened up a new potential vulnerability.
To me, scenario 2B looks worse than 2A.
Hello Coward.
Yes, HTTP is a pretty complex protocol. However, you can write extremely simple read-only servers, such as thttpd or publicfile.
Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.
Distribution makes untrusted input problems worse since components of your 'server' can no longer even trust each other.
The version control system doesn't trust the web server, or receive any input from the network.
Thankyou for trolling!
More on this:
Why would companies react slowly? They ought to have all the capabilities of free projects, plus money. How is it possible that they perform worse?
I don't know, but I have some theories:
- Companies tend to grow bureaucracy, which prevents fast action. Open source developers can just commit the change and be done.
- Companies don't like to admit they had mistakes.
- Vulnerability reports in open source are more likely to point out where the problem is, which makes it easier to fix.
- Open source projects can draw on a lot of highly-qualified resources in the community for advice.
Systems which are more fixable, or more quickly fixed (which is slightly different) present a real-world advantage.
Discovery of a vulnerability in say CVS or IIS does not mean every installation in the world will be compromised immediately. It means that the clock starts ticking. If a fix is released and applied more quickly, then there is less risk that any given machine will be compromised. Look at Schneier's "exposure envelope" model.
Historically open source has done reasonably well, though not perfectly, at releasing fixes very soon after vulnerabilities become known to the author. Open source projects tend to also be more responsive to reports, which encourages security reporters to do the right thing and report to the authors, knowing that they will get a quick response and proper credit.
There are many reports of proprietary companies sitting on vulnerabilities for more than a year. I have seen Microsoft sit on one for a couple of months. That is an enormous exposure. Being able to fix it yourself may be cold comfort but it's better than having your machines rooted.
It might be more effective to splash it around their torso, but not the cigarette. That way the cigarette won't be doused, but it can ignite the vapor. Obviously you should remove the idiot to a safe distance before doing this.
Just update CVS from FreeBSD whenever they apply the fix. If FreeBSD haven't made a new release yet, then you might want to turn off public access until it's fixed.
I wonder how many virus would be released that will take advantage of these security holes.
I think it's pretty unlikely there will be even one.
The number of machines in the world running public CVS servers must be pretty low: probably hundreds or thousands, but that's tiny compared to the number running Linux or Apache, let alone Windows. A worm that tried to propogate by scanning networks, as most do, would probably fizzle out. I don't think it would be worth the effort to write a virus.
Add to this the fact that CVS servers are probably a bit more diverse in OS/architecture than desktops, and that owners of CVS server probably pay a little more attention to them than does your average desktop user.
Anyone who wants to exploit this hole would be more likely to try to do it by hand against targetted important machines.
Any sane person running anoncvs should have it in a chroot jail, where an attack would cause less damage.
These vulnerabilities are a consequence of an architectural security flaw in both CVS and Subversion: they require an active server that talks a complex protocol to an unauthenticated client.
Whenever you allow an untrusted client to control code running on your server, there is a risk of a compromise.
The distributed version control systems Darcs and Arch show a better way. Read-only access requires only some read-only files published over HTTP. Since most projects already have a web site, this means there is no increase in the network services that need to be offered.
Once those files are downloaded, the anonymous user can get updates, make their own patches, branch -- all the facilities allowed by anonsvn/anoncvs and more.
Which one happens depends on the libc and the allocation pattern, but for any app on any particular system it may be predictable.
The one that is easiest to exploit is writing over another variable, like b. This gives the attack a way to write into a variable they weren't meant to access, which leads in short order to the computer being stretched wide open.
Dr Hos'e may have indulged in the trollish arts in the past, but he does have a point:
how many otherwise great programmers and source control systems gurus cannot post bugfixes to CVS and Subversion codebases thanks to Bitkeeper's EULA
I've received patches from kernel developers for my open source programs. The BK licence makes them give up the right to file CVS or Subversion bug reports, in order to use BK for free.
I don't think CVS or Subversion would suit Linus's style, but maybe Arch or Darcs will in the future.
No amount of code review, open source or proprietary, can guarantee that there isn't some lurking bug in the application.
+5 insightful? More like +1, No Shit Sherlock.