SourceForge needs to be a lot more forthcoming with is report on what happened and how they responded. I assume that the crackers got root access?
According to security theory, the hard drives of the servers affected need to be wiped. The OS needs to be reinstalled, reconfigured, and the backups need to be brought back onto the system auditing configs & data as you go for cracker changes.
In theory, once a computer is compromised at root level, there is no way to know whether you have completely eradicated all traces of the cracker. If you find 56 backdoors and take them all out, you might miss #57. Trojan binaries replacing system binaries, entries in inittab and inetd.conf, introduced kernel modules, additions to/etc/rc, changes to source code on the system that the cracker guesses will be compiled and run, additions in ~/.profile's, daemons left running, the list goes on and on. Tripwire cannot detect everything, and that's only relevant if you've been using it in the first place.
Yes, in some cases I've worked on compromised servers for companies and they don't or can't take it offline right away so it has to stay up. I'm guilty of the post-hack one-day sweep where you clean out the crud and lock it down, warn the client profusely of the dire nature of such actions, and hope for the best. But that's not ideal security procedure.
SourceForge is the single most highly rated, most visible, most acknowledged and respected source repository and project worksite in the OSS community. If a compromise lingers that were to introduce snippets of code into main()'s as source was compiled into binaries, we could be fscked. How embarrassing would that be for the community? Imagine if a newpaper reporter downloads an rpm from SourceForge expecting to run a cool new app and it tells him that ALL YOUR HARD DRIVE ARE BELONG TO US.
I think Microsoft is going to have to swallow hard and accept the fact that while Joe Sixpack may find his computer complex and doesn't find it odd that it crashes every once in a while, he is going to be horribly insulted when his game console crashes. ("What the..? Piece of shit..")
This is one arena where MS is not the "OS" leader. Nintendo, Sega, Sony, even Atari have established "operating systems" that work damn well on their games boxes and don't blue screen every couple of hours. The fact that XBox crashed in such a high-profile tradeshow displays pathetic programming. When Joe Sixpack learns that this is what he can expect from XBox, he will quite simply go with one of the established gaming vendors that has a box that can actually run.
They have the same problem that Volswagon did - their product works extremely well for a long time and nobody feels the need to "upgrade".
My Palm(Pilot) with USRobotics emblazened upon it was one of two that my business partner and I bought for $400 each "back in the day"... they still work and we still use them to this day.
I'm having a slightly hard time picturing water coming out of a faucet at 250 degrees, given that the boiling point of H20 is 212F. Wouldn't that "superheated water" be what most of us refer to as "steam"?
Actually 60 Minutes (I believe) did a segment on superheated water causing injury. They showed a bowl of "soup" (water with a thin layer of oil on top) heated in a perfectly round glass bowl in a common microwave which was over the boiling point in temperature but not moving. When touched with a spoon, the water violently began boiling in a mini-explosion that sprayed it up quite a few inches (enough to hurt your face/arms). The properties of water require miniscule imperfections in your container to provide the "seed" for steam to escape.
Apparently the #1 use for microwaves is to heat water in the morning for coffeee, they reported, and so it was done as a warning piece. Very neat to see it. The term their scientist used was "superheated".
Anyway I think the actual physical properties preclude using it in the way presented, but the theory is not entirely unsound.
The GPL operates as a license to copy. If nobody owns the copyright then who will initiate the lawsuits against people misusing the Nautilus code? (e.g. adding custom improvements and then distributing binaries but refusing to release the source code of those improvements)
They should assign it to FSF before they disolve, or something.
In addition, any
disclosure of information gained from participating in the Public Challenge would be outside the scope of activities permitted by the
Agreement and could subject you and your research team to actions under the Digital Millennium Copyright Act ("DCMA").
Oh, no, hold it... they are threatening to sue under the Dumbass Chickens who Misuse Agreements law... not the _D_igital _M_illenium _C_opyright _A_ct. Oh, thank God. Don't worry guys, everybody go home, it's just the DCMA, thankfully not the DMCA.
If I was Princeton, I would write back and say nothing except, "Can we have the spell-checked version of your letter now? Then we'll consider it. Thanks."
So the warranty disclaimer doesn't apply to anyone
who doesn't copy code.
Except of course the original copy you performed to get the software onto your system in the first place. You then bind your organization.
From a purist point of view, you may be right though. But two things spring to mind: (a) merchantability and fitness for a particular purpose are implied warranties enforced as public policy to protect buyers and generally entitle you to a refund and return if they are failed - I don't think they go much beyond that, so in the case where the software is free there isn't too much to refund. (b) Maybe the GPL is a new animal waiting to be tested by the courts. It's like a writ from the old days - a copyright holder's writ of authorization exempting everyone from infringing federal copyright law. Maybe the courts will extend warranty disclaimers to such things because of the success of the GPL? Not something to bank on, but worth pondering...
This post highlights the particular lack of service and bad attitute of one company but I believe it brings up some interesting issues that the entire Internet community is dealing with now, even the best of us.
Unfortunately, many dedicated server hosting providers are not addressing security, but even with those that are, the assurance level of staying secure is not too high. Why? Because as security guru Bruce Schneier preaches, security is a process, not a product. The security "posture" (as we call it around my office) of your server is deeply intertwined with the goals that you are trying to achieve, the amount and types of access you need to create for legitimate maintenance, your corporate culture (and specifically aversion to risk), and the technical competency and training abilities of your IT staff or consultants.
Because security is a process, not a product, it's difficult for a hosting company to wrap it up in a nice neat bundle for $299.99/month - especially when in the same breath they speak of giving you telnet access and "complete control".
My firm recently handled the "cleanup" of three different cracks for three different companies. The proper response is to setup a new, fresh server, with (what probably never existed before) a "defensive" security posture instead of the "open" security posture that most setups default to. The report that we create documenting the custom modifications and configurations for the new posture is ~60 pages long and represents a good chunk of time. We are in the service business dealing with web design, programming, and management so this is a natural extension of our services. Web hosting companies, however, are increasingly finding themselves in a commodity business - witness the mass consolidation of hosting organizations to leverage resources and the dwindling of the mom & pop hosting shops. In my mind this isn't bad, actually - it allows specialization and is the natural evolution of any complex field into several disciplines.
I'll comment on Cobalt because we've dealt with their RaQ 3 servers. Cobalt servers are not secure and are incredibly difficult to make secure while preserving any remnant of "Cobaltness". As an example of the type of thinking at Cobalt, they configure their boxes to run two Apache daemons - one for the public site(s), and one for administration access. The administrative daemon *runs as root*, so that the CGI programming within their (very nice looking) admin GUI can then do lots of useful things. Anyone who seriously administrates *nix boxes connected to the Internet is surely raising an eyebrow (if not shaking their head in disbelief).
A more specific problem with the Cobalt system is security updates. The Cobalt Linux distro is based on Red Hat but so heavily customized that you really waste time administering it in ways other than through their interface. Normal Red Hat gurus are *not* going to feel at home on this type of box. Cobalt patches do get posted on their public web site, but they typically lag behind the corresponding Red Hat fix. Here are some facts:
Red Hat posted a RHSA to update to bind 8.2.2_P7 on 11/27/00 whereas Cobalt did not post this until 01/16/01.
Red Hat posted a RHSA to update to bind 8.2.3 on 01/29/01 whereas Cobalt did not post this until 02/06/01.
Moreover, automatic update is an issue. To update a Red Hat system automatically is easy, and has been since the 6.x series - we always recommend that servers check for updates daily and without any human intervention download and install new software. As a manager, you should get an email the next day just summarizing the fact that a new package was installed. The work that Red Hat is now doing with their Red Hat Network is going to make this even more robust and intelligent in the future. (I believe this is so important now because the black hat community watches for Red Hat vulnerabilities and pounces on announcements.) I am not aware of any provided method to update a Cobalt server like this daily, and if such a system were available, it should be installed and turned on by default to follow up on Cobalt's plug-and-play marketing promises. Even so, the default security posture and the inflexibility of the system is not appealing anyhow.
Now does the Cobalt system have it's pluses? You bet - it's great for simple administration of lots of straightforward web sites. It's bad for developers who want to get their hands dirty.
I think from here we go forward two ways. First, over the near future there is a natural progression that can and will be made in the security defaults and simple configurability of major distributions and web hosting offerings. This will happen. Second, I believe knowledge and skills in network survivability (and security as a subset of that) will grow in importance and companies will need to hire or contract it to keep things "humming" without interruptions. Organizations that don't want to address this and just want a simple web site will probably stick to lower-cost shared hosting plans where the environment is controlled by administrators at the ISP's who will be responsible for the assurance level of security.
This means that the copyright system in general is anti-free software. If you have to get a new copyright on every
cvsupdate you make, there is no way any individual working out of his or her garage could manage this. Sure, you
may file copyright on version 1.0, but when you release 1.2 (which adds few new features), suddenly that version is
not copyrighted?
No... you're thinking like a programmer. It's not a true/false boolean flag.:-)
The law is about positions. What is our position, what is their position. The more evidence you have to sway a jury, the stronger your position can be, and the more demanding you can be.
Registration of your 1.0 source would definitely help in a legal battle even if you had progressed to 1.5, because at least you can show the exact date when 1.0 was registered, and show that 70% of the code is the same, plus a changelog to show the additions. A certification from a government entity is one of those things that pushes your position forward. I wouldn't worry about whether the exact version you are working on now is registered. After all, in terms of what we're talking about, your goal is to convince a group of 12 reasonable people that you have the natural copyright privilege to version 1.5 of this source - a government document showing where you were at version 1.0 is a great element to put on the timeline to strengthen your claim.
If nothing else, it would certainly prove what the license terms were at 1.0 if that was part of your filed materials, and most juries will understand that the license is not likely to change between 1.0 and 1.5.
Funny how the German minister's quoted comments were towards a contract in place with MS, not about, for example, their satisfaction in using MS products.
Almost as if someone called over to Germany to "remind" them of their "contractual obligations".
(1) If software is delivered via the web, you will require someone else?s computing power at the other end
of the line. Someone has to pay for this. As the recent experience of the dotcoms shows, business models
based on giving stuff away free almost invariable don?t work. Software provides will have to be paid for the
service they provide. So an end to the free beer aspect of software.
"Software at the other end of the line" -- you mean like the programs you run on a server over telnet or ssh? I see a direct parallel between software that you run by typing a command and software that you run by entering a URL.
The only difference, IMHO, is that software on a URL can be made much more easily available to "anonymous" use, i.e. the public. But there is nothing to say that you couldn't make the source code available for such a program any more than the source code for any program you use on a corporate, university, or hobby server.
We've always had closed source sofware (and always will) and those who publish closed-source will probably move quite easily over to web-based systems. I *prefer* that - why? Because when a Win program crashes on my computer there's no easy way to report that crash with any meaningful information to a programmer. Whereas in a web-based model, the developers responsible are closer to the software, closer to the logs, usually very familiar with their server environment which is standardized, and can make incremental improvements easier. (I should know, I program a lot for the web.)
Those of us who believe in open-source can still download the source to web program x and play with it, provided that the developers make that source downloadable. Witness Slashcode. I will concede, though, that these programs are typically more complex in regards to dependencies on outside configuration, software, etc. (any mod_perl script, which I believe Slashdot runs as, for example, is heavily dependent on the way Apache is configured and compiled)
just need a couple language extensions
on
Anticryptography
·
· Score: 1
# declarations
Use lang.math.sine[100.1.2.3] as sine
Use graphics.2d.drawline[95.2.1.1] as drawline
Use lang.math.pi[100.1.2.1] as pi
The component system does seem like a good idea, but it's actually almost what we've got now. In Perl, if you're missing a module you can usually grab it off CPAN if it's a popular one - that could be automated. You could even introduce more general language extensions to help:
#!/usr/bin/perl
use strict;
use HTML::Parse available at http://www.somesite.com/perl/htmlparse/;
use Math::FuzzyLogic available at ftp://www.maththings.org/pub/math/fuzzylogic/;
use Popular::Module available via CPAN;
Each directory pointed to by an 'at' could house a.tar.gz, an.rpm, a.deb, etc., with an index thereof. The 'via' keyword could signal archives such as CPAN for which a more elaborate system is engaged.
Later you could add version control:
#!/usr/bin/perl
use strict;
use HTML::Parse available at 'http://www.somesite.com/perl/htmlparse/', need 5.0;
use Math::FuzzyLogic available at 'ftp://www.maththings.org/pub/math/fuzzylogic/', need 4.1.7+;
use Popular::Module available via 'CPAN', need 1.2+;
Programs can be built by linking to instructions in other programs (much like most software built today is based on modular design). Once they reach this point, all they need to do is archive programs and execute them to see what they do (much like you use desktop publishing software without having to understand the function of every DLL or class library used to build it).
Great, all we need is Microsoft sending aliens DLL's. I'm sure that will promote intergalactic peace.
> Surely you can understand the need to patch critical pieces of
> infrastructure such as the root, gTLD and ccTLD name servers
> and to prepare patched binaries of BIND for various operating
> systems before the vulnerability becomes widely known.
Of course. But how long do you give downstream developers? Do you give
them N days, and when N+1 appears will the forum embarrass paying members
of your group? If everyone signs an NDA, no-one can squeal. Can a time
limit be put on the NDAs?
What would be ideal is if the NDA's had a time limit, say 21 days from initial discovery, during which the list remained quiet and worked on a fix, and then on the 22nd day the NDA *required* the members to all divulge the news, say on their respective web sites. That way, the leader of the group is not put into a position of having to divulge the news and embarrass one of it's own members; they all do it together without choice.
I think this group should also think about the number of days that is required for silence and put a limit on it from the beginning. There should be one mechanism for an extension of a fixed amount, and that's it. No member should be able to drag out the process. In any case, the news should be public within 30-45 days MAX.
On the subject of patents, I believe reform is in order, as relates to Internet technologies. Here's my idea.
1. If amazon.com or some business legitimately creates a cool new concept for web sites (they did *not* with 1-click, IMHO, BTW), then grant them a patent; but it should last for some short amount of time commensurate with the relevance of the claimed discovery. If were examining their 1-click patent, I'd grant them 6 months on it. The time and money they spent on it, combined with the fact of it being almost obvious to a web programmer, makes it much less of an innovation, than say a biological filtering process which cost a company $25,000,000 and took 7 years to develop, or a cure for AIDS which took 25 years and countless dollars. I would recommend having classes of patents to make things simpler. Class A could be 6 month patents for minor improvements to existing technologies in which you spend less than $10,000 DIRECTLY and less than 2 months IMPLEMENTING; Classes B, C, D get higher on the expenditures and importance; if you don't meet the requirements for your claimed class, you are bumped down to the most appropriate one.
2. An entity independent of the USPTO and respected in your industry must certify that your patent meets existing patent laws plus the appopriateness of your class in the class system I outlined above. For amazon's 1-click patent, such an entity might be W3C, IETF, or some web developer's guild. USPTO would pick the entity and the applicant would pay a fee to the USPTO which is passed on to the entity for consideration of their certification service. The general public could petition the USPTO to help select the entity - perhaps for that particular application or just all applications within an industry group. If the entity won't certify, it can recommend a class downgrade or reject the application (for prior art, perhaps).
This eliminates the need for the USPTO to be an expert in every single industry, and eliminates the need for all patents to be tested in court before being worth anything (as is now). Currently, companies can get patents on damn near anything, and then use it against thousands of small businesses; it's not until a large competitor comes along to defend itself in court that the patent gets overturned.
Unless the IT-ISAC can somehow contain such technical experts, the holes in their system will continue to be an open book.
Ok. Done...
IT-ISAC Reporting Society: Join our reporting society and earn $400 cash for any new security exploit that you find and report!
Terms & Conditions:..... blah blah.....
5(g) Reporter agrees to refrain from disclosing to any third party and refrain from publishing, communicating, transmitting, or posting the Exploit, in any manner, other than as provided above in 2(a) Reporting Procedure...... blah blah.....
If you've found something, unless you have a strong personal interest in free security information, why wouldn't you want to make a few bucks?
foobar - unix utility
Copyright (C) 2000 John Smith
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version EXCEPT if you are Microsoft Corp or a subsidiary of the same.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
have shown that most users rely on less than 10 percent of the features of common programs as Microsoft Word or Netscape Communicator.
Perhaps the biggest irony in all this is that the shoddiness of high-tech products means that people don't use more than a very small fraction of the innovations developed at breakneck speed that are supposed to justify high-tech sloppiness.
God forbid we toot the horn of free software here.;-P
It seems to me that the tradition and philosophy of free software lends itself to smaller programs, ones that can fit into one person's head and be maintained by basically one person. Sure, we have teams working on GNOME, etc., but essentially those projects get broken up into pieces.
The (closely related) *nix philosophy is to use hundreds of small programs in concert; each program does one thing and one thing well.
This type of system promotes far more stable software in the long run, since modularization and testing is inherent in the methodology. Let's face it, when we discuss bad software, 90% of Slashdotters conjure up images of Windows, little boxes with stop signs and the dopiest, vaguest error messages man has ever written, and blue screens.
What we need to do as a community is insist that the commercialization of Linux does not involve the adoption of bloated programs into *nix-space.
I'll give you an example that is fresh on my mind - the up2date program on Red Hat that keeps your system in-sync should not be a GUI+CLI program as it is now. They should separate it into two parts, a CLI program that does the grunt work and can be used from/etc/cron*, and a GUI program that interfaces to it. At the moment if you install the up2date.rpm the system will moan and complain if you don't have GNOME, X, etc. installed, despite the fact that you might plan to only use it in CLI. And --nodeps is a silly cop out IMHO. (Fix rather than diagnose as the article author would say.)
Don't forget about the UNIX tools philosophy that serves us so well - many programs, each doing one thing, and one thing well, acting in concert. (Bloatware is bad.)
</nostalgia>
Even if you're not planning to design your project like this, let us interact with its data files or database rows with command line interface tools, both standard ones and ones that you provide. This makes scripting that much easier. It also keeps the data as "open" as the source code. ("Open Data Software"... hmm...)
<rant point="little to none">
And for God's sake don't make it store all its data in XML. I can't stand programs that do that. It's so much more work to parse. Give me mysql/mysqldump and grep/sed/awk/perl any day. XML is a very good transfer/transmission psudeo-language, for platforms to talk to each other, not for storing data on disk.
</rant>
Jay: Yes, definitely. In fact, I'm currently working on a new internal architecture that easily
supports this. In essence, we simply have to keep track of and store more data about each
distribution. On top of this, we have to check the state of the system more thoroughly,
looking for general files, instead of packages. We'll be able to support a lot more than just
Red Hat Linux and Linux Mandrake.
Unfortunately, I don't think we'll ever get to the point where we can dictate file locations to
the distribution makers. They're not even maintaining the same file locations from release
to release! I think it's mostly an issue of preference for their individual package maintainers,
really.
It dawned on me recently that Linux might benefit from a set of "meta-distribution" data stored in a defined location. You could start with defining the basic distribution and then let people/packages add additional data later.
In more intuitive terms, have an/etc/distro directory which contained certain predefined files.
Obviously this idea is simplistic and would need extending before it would be useful. But is it realistic that eventually a collection of meta-distribution files on the hard drive could help people like Jay working on Bastille by taking some of the guess-work out and saving some programming time?
For example, if Red Hat (or someone who put together a RH-specific metafile) provided a shortlist of certain important files and their locations, which Bastille could easily query, when a new RH comes out that changes a file location, one need only change the described location in the metafile, and Bastille could continue to function untouched.
Or maybe we could standardize on a package query script at/etc/distro/package which on RH would be a script that does "rpm -q" but on other distros, e.g. Debian, could do something else to detect if a package was installed.
These are embryonic thoughts - anyone have more solid ideas for this type of thing?
Instead, what if a good hacker decided to drop a few dozen lines of code in amongst the 10s of millions or so lines
in Windows to make it easier for *them* to hack. Why hunt down security holes, when you can code them into
the product yourself.
You know, what's to stop this from happening to an Open Source product? Your average Linux distro is a few hundred separate packages - who's to say someone doesn't hack into an author's computer and add a few lines to his project for him?
What with all these binary.rpm's and all these days, it might be a while before anyone noticed... I know I certainly don't have time to read the code of every program I want to use.
So I suppose my point is - in light of those two points above, isn't a scenario like this *more likely* with Open Source?
It just occurred to me that AFAIK, Red Hat, the particular vendor I use for Linux, doesn't actually advertise that they read every line of source code for intentional "vulnerabilities". (Or do they?)
Hmmmmmm.... let me play Devil's advocate - what if M$ (or some entity controlled thereof) did this intentionally to undermine Linux? i.e. coded something that Linux badly needed, and then intentionally coded in a subtle backdoor and released an exploit under the table, followed shortly thereafter by appropriate FUD.
Slashdot Mirror
Let's keep in mind that the author is not actually a lawyer yet, despite being published in the journal.
SourceForge needs to be a lot more forthcoming with is report on what happened and how they responded. I assume that the crackers got root access?
/etc/rc, changes to source code on the system that the cracker guesses will be compiled and run, additions in ~/.profile's, daemons left running, the list goes on and on. Tripwire cannot detect everything, and that's only relevant if you've been using it in the first place.
According to security theory, the hard drives of the servers affected need to be wiped. The OS needs to be reinstalled, reconfigured, and the backups need to be brought back onto the system auditing configs & data as you go for cracker changes.
In theory, once a computer is compromised at root level, there is no way to know whether you have completely eradicated all traces of the cracker. If you find 56 backdoors and take them all out, you might miss #57. Trojan binaries replacing system binaries, entries in inittab and inetd.conf, introduced kernel modules, additions to
Yes, in some cases I've worked on compromised servers for companies and they don't or can't take it offline right away so it has to stay up. I'm guilty of the post-hack one-day sweep where you clean out the crud and lock it down, warn the client profusely of the dire nature of such actions, and hope for the best. But that's not ideal security procedure.
SourceForge is the single most highly rated, most visible, most acknowledged and respected source repository and project worksite in the OSS community. If a compromise lingers that were to introduce snippets of code into main()'s as source was compiled into binaries, we could be fscked. How embarrassing would that be for the community? Imagine if a newpaper reporter downloads an rpm from SourceForge expecting to run a cool new app and it tells him that ALL YOUR HARD DRIVE ARE BELONG TO US.
I think Microsoft is going to have to swallow hard and accept the fact that while Joe Sixpack may find his computer complex and doesn't find it odd that it crashes every once in a while, he is going to be horribly insulted when his game console crashes. ("What the..? Piece of shit..")
This is one arena where MS is not the "OS" leader. Nintendo, Sega, Sony, even Atari have established "operating systems" that work damn well on their games boxes and don't blue screen every couple of hours. The fact that XBox crashed in such a high-profile tradeshow displays pathetic programming. When Joe Sixpack learns that this is what he can expect from XBox, he will quite simply go with one of the established gaming vendors that has a box that can actually run.
They have the same problem that Volswagon did - their product works extremely well for a long time and nobody feels the need to "upgrade".
My Palm(Pilot) with USRobotics emblazened upon it was one of two that my business partner and I bought for $400 each "back in the day"... they still work and we still use them to this day.
Actually 60 Minutes (I believe) did a segment on superheated water causing injury. They showed a bowl of "soup" (water with a thin layer of oil on top) heated in a perfectly round glass bowl in a common microwave which was over the boiling point in temperature but not moving. When touched with a spoon, the water violently began boiling in a mini-explosion that sprayed it up quite a few inches (enough to hurt your face/arms). The properties of water require miniscule imperfections in your container to provide the "seed" for steam to escape.
Apparently the #1 use for microwaves is to heat water in the morning for coffeee, they reported, and so it was done as a warning piece. Very neat to see it. The term their scientist used was "superheated".
Anyway I think the actual physical properties preclude using it in the way presented, but the theory is not entirely unsound.
So who gets the copyright assignment to Nautilus?
The GPL operates as a license to copy. If nobody owns the copyright then who will initiate the lawsuits against people misusing the Nautilus code? (e.g. adding custom improvements and then distributing binaries but refusing to release the source code of those improvements)
They should assign it to FSF before they disolve, or something.
In addition, any disclosure of information gained from participating in the Public Challenge would be outside the scope of activities permitted by the Agreement and could subject you and your research team to actions under the Digital Millennium Copyright Act ("DCMA").
Oh, no, hold it... they are threatening to sue under the Dumbass Chickens who Misuse Agreements law... not the _D_igital _M_illenium _C_opyright _A_ct. Oh, thank God. Don't worry guys, everybody go home, it's just the DCMA, thankfully not the DMCA.
If I was Princeton, I would write back and say nothing except, "Can we have the spell-checked version of your letter now? Then we'll consider it. Thanks."
So the warranty disclaimer doesn't apply to anyone who doesn't copy code.
Except of course the original copy you performed to get the software onto your system in the first place. You then bind your organization.
From a purist point of view, you may be right though. But two things spring to mind: (a) merchantability and fitness for a particular purpose are implied warranties enforced as public policy to protect buyers and generally entitle you to a refund and return if they are failed - I don't think they go much beyond that, so in the case where the software is free there isn't too much to refund. (b) Maybe the GPL is a new animal waiting to be tested by the courts. It's like a writ from the old days - a copyright holder's writ of authorization exempting everyone from infringing federal copyright law. Maybe the courts will extend warranty disclaimers to such things because of the success of the GPL? Not something to bank on, but worth pondering...
I'm not a lawyer.
Brad .. Wins </voice>
This post highlights the particular lack of service and bad attitute of one company but I believe it brings up some interesting issues that the entire Internet community is dealing with now, even the best of us.
Unfortunately, many dedicated server hosting providers are not addressing security, but even with those that are, the assurance level of staying secure is not too high. Why? Because as security guru Bruce Schneier preaches, security is a process, not a product. The security "posture" (as we call it around my office) of your server is deeply intertwined with the goals that you are trying to achieve, the amount and types of access you need to create for legitimate maintenance, your corporate culture (and specifically aversion to risk), and the technical competency and training abilities of your IT staff or consultants.
Because security is a process, not a product, it's difficult for a hosting company to wrap it up in a nice neat bundle for $299.99/month - especially when in the same breath they speak of giving you telnet access and "complete control".
My firm recently handled the "cleanup" of three different cracks for three different companies. The proper response is to setup a new, fresh server, with (what probably never existed before) a "defensive" security posture instead of the "open" security posture that most setups default to. The report that we create documenting the custom modifications and configurations for the new posture is ~60 pages long and represents a good chunk of time. We are in the service business dealing with web design, programming, and management so this is a natural extension of our services. Web hosting companies, however, are increasingly finding themselves in a commodity business - witness the mass consolidation of hosting organizations to leverage resources and the dwindling of the mom & pop hosting shops. In my mind this isn't bad, actually - it allows specialization and is the natural evolution of any complex field into several disciplines.
I'll comment on Cobalt because we've dealt with their RaQ 3 servers. Cobalt servers are not secure and are incredibly difficult to make secure while preserving any remnant of "Cobaltness". As an example of the type of thinking at Cobalt, they configure their boxes to run two Apache daemons - one for the public site(s), and one for administration access. The administrative daemon *runs as root*, so that the CGI programming within their (very nice looking) admin GUI can then do lots of useful things. Anyone who seriously administrates *nix boxes connected to the Internet is surely raising an eyebrow (if not shaking their head in disbelief).
A more specific problem with the Cobalt system is security updates. The Cobalt Linux distro is based on Red Hat but so heavily customized that you really waste time administering it in ways other than through their interface. Normal Red Hat gurus are *not* going to feel at home on this type of box. Cobalt patches do get posted on their public web site, but they typically lag behind the corresponding Red Hat fix. Here are some facts:
Red Hat posted a RHSA to update to bind 8.2.2_P7 on 11/27/00 whereas Cobalt did not post this until 01/16/01.
Red Hat posted a RHSA to update to bind 8.2.3 on 01/29/01 whereas Cobalt did not post this until 02/06/01.
Moreover, automatic update is an issue. To update a Red Hat system automatically is easy, and has been since the 6.x series - we always recommend that servers check for updates daily and without any human intervention download and install new software. As a manager, you should get an email the next day just summarizing the fact that a new package was installed. The work that Red Hat is now doing with their Red Hat Network is going to make this even more robust and intelligent in the future. (I believe this is so important now because the black hat community watches for Red Hat vulnerabilities and pounces on announcements.) I am not aware of any provided method to update a Cobalt server like this daily, and if such a system were available, it should be installed and turned on by default to follow up on Cobalt's plug-and-play marketing promises. Even so, the default security posture and the inflexibility of the system is not appealing anyhow.
Now does the Cobalt system have it's pluses? You bet - it's great for simple administration of lots of straightforward web sites. It's bad for developers who want to get their hands dirty.
I think from here we go forward two ways. First, over the near future there is a natural progression that can and will be made in the security defaults and simple configurability of major distributions and web hosting offerings. This will happen. Second, I believe knowledge and skills in network survivability (and security as a subset of that) will grow in importance and companies will need to hire or contract it to keep things "humming" without interruptions. Organizations that don't want to address this and just want a simple web site will probably stick to lower-cost shared hosting plans where the environment is controlled by administrators at the ISP's who will be responsible for the assurance level of security.
No... you're thinking like a programmer. It's not a true/false boolean flag. :-)
The law is about positions. What is our position, what is their position. The more evidence you have to sway a jury, the stronger your position can be, and the more demanding you can be.
Registration of your 1.0 source would definitely help in a legal battle even if you had progressed to 1.5, because at least you can show the exact date when 1.0 was registered, and show that 70% of the code is the same, plus a changelog to show the additions. A certification from a government entity is one of those things that pushes your position forward. I wouldn't worry about whether the exact version you are working on now is registered. After all, in terms of what we're talking about, your goal is to convince a group of 12 reasonable people that you have the natural copyright privilege to version 1.5 of this source - a government document showing where you were at version 1.0 is a great element to put on the timeline to strengthen your claim.
If nothing else, it would certainly prove what the license terms were at 1.0 if that was part of your filed materials, and most juries will understand that the license is not likely to change between 1.0 and 1.5.
Please note, IANAL.
Funny how the German minister's quoted comments were towards a contract in place with MS, not about, for example, their satisfaction in using MS products.
Almost as if someone called over to Germany to "remind" them of their "contractual obligations".
"Software at the other end of the line" -- you mean like the programs you run on a server over telnet or ssh? I see a direct parallel between software that you run by typing a command and software that you run by entering a URL.
The only difference, IMHO, is that software on a URL can be made much more easily available to "anonymous" use, i.e. the public. But there is nothing to say that you couldn't make the source code available for such a program any more than the source code for any program you use on a corporate, university, or hobby server.
We've always had closed source sofware (and always will) and those who publish closed-source will probably move quite easily over to web-based systems. I *prefer* that - why? Because when a Win program crashes on my computer there's no easy way to report that crash with any meaningful information to a programmer. Whereas in a web-based model, the developers responsible are closer to the software, closer to the logs, usually very familiar with their server environment which is standardized, and can make incremental improvements easier. (I should know, I program a lot for the web.)
Those of us who believe in open-source can still download the source to web program x and play with it, provided that the developers make that source downloadable. Witness Slashcode. I will concede, though, that these programs are typically more complex in regards to dependencies on outside configuration, software, etc. (any mod_perl script, which I believe Slashdot runs as, for example, is heavily dependent on the way Apache is configured and compiled)
The component system does seem like a good idea, but it's actually almost what we've got now. In Perl, if you're missing a module you can usually grab it off CPAN if it's a popular one - that could be automated. You could even introduce more general language extensions to help:
#!/usr/bin/perl
use strict;
use HTML::Parse available at http://www.somesite.com/perl/htmlparse/;
use Math::FuzzyLogic available at ftp://www.maththings.org/pub/math/fuzzylogic/;
use Popular::Module available via CPAN;
Each directory pointed to by an 'at' could house a .tar.gz, an .rpm, a .deb, etc., with an index thereof. The 'via' keyword could signal archives such as CPAN for which a more elaborate system is engaged.
Later you could add version control:
#!/usr/bin/perl
use strict;
use HTML::Parse available at 'http://www.somesite.com/perl/htmlparse/', need 5.0;
use Math::FuzzyLogic available at 'ftp://www.maththings.org/pub/math/fuzzylogic/', need 4.1.7+;
use Popular::Module available via 'CPAN', need 1.2+;
Great, all we need is Microsoft sending aliens DLL's. I'm sure that will promote intergalactic peace.
What would be ideal is if the NDA's had a time limit, say 21 days from initial discovery, during which the list remained quiet and worked on a fix, and then on the 22nd day the NDA *required* the members to all divulge the news, say on their respective web sites. That way, the leader of the group is not put into a position of having to divulge the news and embarrass one of it's own members; they all do it together without choice.
I think this group should also think about the number of days that is required for silence and put a limit on it from the beginning. There should be one mechanism for an extension of a fixed amount, and that's it. No member should be able to drag out the process. In any case, the news should be public within 30-45 days MAX.
Copyright is crap.... blah, blah, blah, blah.... copyright is crap...
...
Copyright © 2001 National Post Online | Privacy Policy | Corrections
Um. Ok, dude. Whatever.
On the subject of patents, I believe reform is in order, as relates to Internet technologies. Here's my idea.
1. If amazon.com or some business legitimately creates a cool new concept for web sites (they did *not* with 1-click, IMHO, BTW), then grant them a patent; but it should last for some short amount of time commensurate with the relevance of the claimed discovery. If were examining their 1-click patent, I'd grant them 6 months on it. The time and money they spent on it, combined with the fact of it being almost obvious to a web programmer, makes it much less of an innovation, than say a biological filtering process which cost a company $25,000,000 and took 7 years to develop, or a cure for AIDS which took 25 years and countless dollars. I would recommend having classes of patents to make things simpler. Class A could be 6 month patents for minor improvements to existing technologies in which you spend less than $10,000 DIRECTLY and less than 2 months IMPLEMENTING; Classes B, C, D get higher on the expenditures and importance; if you don't meet the requirements for your claimed class, you are bumped down to the most appropriate one.
2. An entity independent of the USPTO and respected in your industry must certify that your patent meets existing patent laws plus the appopriateness of your class in the class system I outlined above. For amazon's 1-click patent, such an entity might be W3C, IETF, or some web developer's guild. USPTO would pick the entity and the applicant would pay a fee to the USPTO which is passed on to the entity for consideration of their certification service. The general public could petition the USPTO to help select the entity - perhaps for that particular application or just all applications within an industry group. If the entity won't certify, it can recommend a class downgrade or reject the application (for prior art, perhaps).
This eliminates the need for the USPTO to be an expert in every single industry, and eliminates the need for all patents to be tested in court before being worth anything (as is now). Currently, companies can get patents on damn near anything, and then use it against thousands of small businesses; it's not until a large competitor comes along to defend itself in court that the patent gets overturned.
I leave ther rest to the lawyers. :-)
Ok. Done...
IT-ISAC Reporting Society: Join our reporting society and earn $400 cash for any new security exploit that you find and report! Terms & Conditions: ..... blah blah .....
5(g) Reporter agrees to refrain from disclosing to any third party and refrain from publishing, communicating, transmitting, or posting the Exploit, in any manner, other than as provided above in 2(a) Reporting Procedure. ..... blah blah .....
If you've found something, unless you have a strong personal interest in free security information, why wouldn't you want to make a few bucks?
hmmm....
[Wayne's World style fuzzy dream sequence...]
Yup... there we go. Game on!
Searches show you where your navigation is failing (especially on home page), or where you might need to add a Q&A to your FAQ.
God forbid we toot the horn of free software here. ;-P
It seems to me that the tradition and philosophy of free software lends itself to smaller programs, ones that can fit into one person's head and be maintained by basically one person. Sure, we have teams working on GNOME, etc., but essentially those projects get broken up into pieces.
The (closely related) *nix philosophy is to use hundreds of small programs in concert; each program does one thing and one thing well.
This type of system promotes far more stable software in the long run, since modularization and testing is inherent in the methodology. Let's face it, when we discuss bad software, 90% of Slashdotters conjure up images of Windows, little boxes with stop signs and the dopiest, vaguest error messages man has ever written, and blue screens.
What we need to do as a community is insist that the commercialization of Linux does not involve the adoption of bloated programs into *nix-space.
I'll give you an example that is fresh on my mind - the up2date program on Red Hat that keeps your system in-sync should not be a GUI+CLI program as it is now. They should separate it into two parts, a CLI program that does the grunt work and can be used from /etc/cron*, and a GUI program that interfaces to it. At the moment if you install the up2date .rpm the system will moan and complain if you don't have GNOME, X, etc. installed, despite the fact that you might plan to only use it in CLI. And --nodeps is a silly cop out IMHO. (Fix rather than diagnose as the article author would say.)
Just my $0.02.
Don't forget about the UNIX tools philosophy that serves us so well - many programs, each doing one thing, and one thing well, acting in concert. (Bloatware is bad.)
</nostalgia>
Even if you're not planning to design your project like this, let us interact with its data files or database rows with command line interface tools, both standard ones and ones that you provide. This makes scripting that much easier. It also keeps the data as "open" as the source code. ("Open Data Software"
<rant point="little to none">
And for God's sake don't make it store all its data in XML. I can't stand programs that do that. It's so much more work to parse. Give me mysql/mysqldump and grep/sed/awk/perl any day. XML is a very good transfer/transmission psudeo-language, for platforms to talk to each other, not for storing data on disk.
</rant>
It dawned on me recently that Linux might benefit from a set of "meta-distribution" data stored in a defined location. You could start with defining the basic distribution and then let people/packages add additional data later.
In more intuitive terms, have an /etc/distro directory which contained certain predefined files.
Imagine:
/etc/distro/vendor
/etc/distro/release
/etc/distro/homepage.url
/etc/distro/security-errata.url
...
Obviously this idea is simplistic and would need extending before it would be useful. But is it realistic that eventually a collection of meta-distribution files on the hard drive could help people like Jay working on Bastille by taking some of the guess-work out and saving some programming time?
For example, if Red Hat (or someone who put together a RH-specific metafile) provided a shortlist of certain important files and their locations, which Bastille could easily query, when a new RH comes out that changes a file location, one need only change the described location in the metafile, and Bastille could continue to function untouched.
Or maybe we could standardize on a package query script at /etc/distro/package which on RH would be a script that does "rpm -q" but on other distros, e.g. Debian, could do something else to detect if a package was installed.
These are embryonic thoughts - anyone have more solid ideas for this type of thing?
I guess /. is only reviewing purple books from now on. Oh well.
You know, what's to stop this from happening to an Open Source product? Your average Linux distro is a few hundred separate packages - who's to say someone doesn't hack into an author's computer and add a few lines to his project for him?
What with all these binary .rpm's and all these days, it might be a while before anyone noticed... I know I certainly don't have time to read the code of every program I want to use.
So I suppose my point is - in light of those two points above, isn't a scenario like this *more likely* with Open Source?
It just occurred to me that AFAIK, Red Hat, the particular vendor I use for Linux, doesn't actually advertise that they read every line of source code for intentional "vulnerabilities". (Or do they?)
Hmmmmmm.... let me play Devil's advocate - what if M$ (or some entity controlled thereof) did this intentionally to undermine Linux? i.e. coded something that Linux badly needed, and then intentionally coded in a subtle backdoor and released an exploit under the table, followed shortly thereafter by appropriate FUD.