My daughter (10) is currently working on learning BASIC on my old PCjr. No, she'll probably never actually apply her "L337" Basic skilz, but she's learning to plan her ideas, and logically comunicate her thoughts to the computer, and that, my friend, is some seriously valuable lessons.
Exactly. Joe User has no idea what software is, where it comes from, what its limitations are, etc. Computers are magic boxes. If students can handle basic chemistry, physics, and algebra, why can't they handle basic computer science?
Computers are such an integral part of society today, yet knowledge of basic computer science is virtually nonexistant. The way people are trained to interact with computers doesn't even give them the necessary information to know what questions to ask to learn how stuff works. I think that this is very unfortunate, and possibly even detrimental to society as a whole. With the computer industry so thoroughly dominated by a single company, I worry that people will end up unable to think "outside the box".
I think that this wacky new licensing policy by Microsoft is particularly dangerous. Most (public) schools in the U.S. don't have nearly enough money for computer resources. If they have to pay Microsoft for a license even for their Macs or non-Windows PCs, then those machines just got that much more expensive. Maybe too expensive to afford.
Hopefully, instead of pushing non-Windows systems out of schools, this license scheme will actually end up pushing Microsoft out of schools. I don't know that schools will be able to justify that, though, considering how ubiquitious MS is in the "real world".
Anyway, I'm rambling. In any case, I know that I would have a very different perspective on computers if I grew up around Windows instead of BASIC. Personally, I've very glad I had BASIC. Otherwise, I might not have learned how to make a computer do something that it couldn't already do. I think more people need to learn the lessons that BASIC taught me about how to interact with computers.
Yes, NTFS supports symlinks. Yes, PIFs (shortcuts) are no substitute for symlinks, and they're not supposed to be.
From what I can gather, NTFS doesn't support symlinks to the same degree as Unix filesystems. It supports "Reparse Points" and "Junction Points", which are described at http://arstechnica.com/paedia/n/ntfs/ntfs5-4.html, but they don't do everything that symlinks do. For example, it doesn't sound like they can point to files, only directories. And I recall reading elsewhere that they must be absolute links, and that relative links aren't supported.
NTFS only has one type of link, I'm unclear on the distinction between symbolic and hard links though. This lets multiple file/folder names point to the same physical location on disk. I.e. foobar.txt in c:\ and Gameplan.txt in c:\Program Files are *the same file* not two seperate files with identical contents. Changes in one change all the other linked files, because it's really the same file.
This is a hard link. I do not believe NTFS (even version 5) supports symlinks. IIRC this was going to be the source of some problems for MS, because they provide a POSIX emulation layer, but the latest POSIX spec requires symlink support in filesystems. I once heard an explanation about why it was going to be difficult for MS to provide this functionality given the fundamental structure of NTFS. Sadly, I don't remember it...
I have Free/SWAN IPSec compiled and ready to test, but it seems like a bit of a nightmare to set up.
It has easily the most confusing documentation and configuration file layout of any VPN-type product i have tried.
Really? I found FreeS/WAN's docs to be amazingly helpful. The config file is certainly a bit different from some of the others out there, but it does work well.
In general IPsec is a great tool for creating VPNs, and since more and more operating systems are including it, it allows for a high level of interoperability (Win2k, Linux, and *BSD, and I think Solaris 8 all include it). The FreeS/WAN people have lots of interop documentation on their site, and as more is written a lot of the current voodoo will be eliminated.
I have recently been doing some interop testing of x.509 certificate-based IPsec authentication between Linux and the KAME implementation (NetBSD, FreeBSD, BDSI), and am writing a document describing the process right now (available at http://web.morgul.net/~frodo/docs/kame+freeswan_in terop.html, though it's not done yet). Certificate-based authentication is great because it eliminates the key distribution problem and makes large-scale deployment a possibility.
The Window Maker feature that really does it for me is the ability to bind keystrokes to windows. An example of this is, when I log in, I bring up an xterm for my mailer. When this window has focus, I press F1. Any subsequent F1 presses will jump focus from whatever window/desktop I might be on to this xterm.
To me, this makes mouseless work much easier, as there's no more switching back & forth between virtual desktops, then tab-cycling through windows to get to the right one. Just one keystroke brings up the window I want.
It's more that the advocates of DRM don't understand that what they are asking is fundermentally impossible. If you want to deliver sound and/or video for people to hear and watch then it can be trivially copied.
Exactly, but I don't think that will necessarily stop them from passing this stupid law. The problem is that this law will require all kinds of effort on the part of software and hardware designers, yet won't change the fact that bits are just bits and there will always be a way to move them around.
Why does SSSCA pose a thread to open source development? What exactly is the problem under this law if I want to run Linux instead of Windows XP? I hear a lot of people saying that this will kill Open Source, but I'm not convinced. Could someone explain this to me?
Easy. Linux won't meet the requirements for DRM that the SSSCA requires. If any Linux distributor decided to implement DRM, the open source nature of the software would allow the user to easily disable or remove it. If you think the SSSCA will allow for easily bypassed DRM, you don't understand what they're going for.
Open source software allows users and developers to take advantage of the power of the tools available to them. This is fundamentally at odds with the SSSCA, which seeks fundamentally to limit the power of those tools.
Is that still true? Last I read they gave a large portion of their address space back.... For all I know they could have kept a coupple million though.
No, it was Stanford that gave up their class A. What were they thinking? MIT still has ungodly amounts of address space. We have net 18 (18.0.0.0/8), plus random assorted/16s (128.52, for example, is the AI lab). There are a couple others.
The thing is, though, there's a whole lot of "reserved" address space out there. The IPv4 address space shortage is partially artificial. In some ways this is to preven the world from grinding to a screeching halt where there really are no more IPv4 addresses. Another is that maybe it will put pressure on people to be conservative with address allocation, which might make the shortage less pressing. Maybe it will also help to speed the deployment of IPv6.
Most OS vendors are already supportind IPv6 out of the box. WinXP, for example, can be set up as an autoconfiguring IPv6 host very easily (ipv6/install at a command prompt, IIRC). The BSDs support it very well, as do many Linux vendors. I think that it won't be long until IPv6 communication on the internet is very widespread. I don't, however, think the whole internet will be IPv6 any time soon.
I wish that more security cameras were webcammed. Who says that only the police shoudl be allowed to know whats going on? What if theres a brutal police beating and the police just "happen" t o lose the video tape? I think corruption among law enforcement officers would be greatly reduced if every security camera were webcammed.
This is absolutely correct, and a very important thing to consider. People don't realize
that their every move is on some camera somewhere. By making the output from these cameras available, people can see what others are seeing. They are more aware of
the fact that they're on camera.
For a much more articulate description of why this is a good thing, please
read David Brin's The Transparent Society. A good
exerpt
can be found at wired.com.
Do Debian's rules explicitly disallow a major version upgrade? Even for security reasons? I believe that boxes are already being exploited. Even if there isn't example code, I'm sure there will be soon. Why wait?
Typically, major version increments are forbidden. In some cases, exceptions must be
made (e.g. a package is rewritten from scratch to correct security problems).
As I said before, there are no known security problems with the current version of OpenSSH 1. There have been in the past, but they've been fixed. It's not that there is no example code, it's that there are no known potentially exploitable security issues in the current OpenSSH shipped with Debian.
Read the changelog for the ssh package./usr/share/doc/ssh/changelog.Debian.gz.
It is still SSH protocol 1, but the ssh daemon is patched to address recent remote
exploit vulnerabilities. There are no known vulnerabilities in the version of OpenSSH
included with Debian 2.2r5.
Still, though, version 2 of the SSH protocol is better, and building updated
OpenSSH packages for potato is not difficult. The 'source' command in apt-get
is very helpful here.
BZZT. Sorry, possession is not illegal under the DMCA, nor could it ever be, since possession of a decryption tool without intent to distribute does not fall under any of the provisions of Article I, Section 8 of the Constution (which would likely be the copyright clause or the interstate commerce clause). A law against possession of decryption tools would be unconstitutional under the 10th ammendment.
OK, but the point of my post is still valid. Even after copyright expires, the law must be broken in order for one to get the tools that allow you to circumvent access controls, even though you do have the legal right to what's on the other side of the access controls. Of course, the law need not be broken if you're on of the very few people in the world capable of cracking CSS without outside information.
The DMCA cases really sound like the lawmakers are trying to reclassify fair use rights as fair use privilages, privilages that we can't complain about losing when they're taken away.
Maybe it is possible that, with the advent of widespread digital communications, copyright law really is obsolete and the DMCA is just a flailing, panicked attempt to prop it up for a bit longer. Maybe copyright can't work as intended anymore... I just wish all this junk would go away so I can spend my time thinking about more interesting problems.
Is it legal to circumvent the access controls on this since it's out of copyright?
Yes.
Yes, you're right. However, it's illegal to posess the tools needed to circumvent the access controls on a work, even after the copyright expires. So whether or not it's legal to circumvent the copy protection is completely irrelevant. You can't legally do it anyway.
Only if those potential uses are sham uses, and the work is primarily created or marketed for copyright circumvention. There are many many software products which have the potential to be used for copyright circumvention, and almost every one is not at all affected by the DMCA.
That's precisely the problem. "...the work is primarily created for copyright circumvention". Aside from the original author of the work, who's to say what the primary purpose of a work is? Hell, the primary purpose of Dr. Felten's work is to merely prove that SDMI is a flawed approach to preventing copyright. Yet RIAA is (apparently) going to succeed at using the DMCA to prevent him from presenting that work. Surely you don't think that the primary purpose of his research is to facilitate copyright infringement.
Oh please. DeCSS was created to circumvent copyright. It was marketed to circumvent copyright. Those legitimate uses are merely incidental. This is not only the ruling the courts made, it is the truth.
Well, if you say so. I suspect, however, that there are a great deal many more people using DeCSS for purely legitimate purposes than for copyright infringement. How many Linux DVD player projects depend completely on its existance? I can think of at least 4 or 5, but I can't name any DVD copying software for any OS that depends on DeCSS.
If I might ask, what do you believe should exist in place of copyright law? Do you believe that all intellectual property should belong to the public domain? I agree that copyright law has major problems (especially after the Sonny Bono Copyright Extension), but I am not sure that legal protection of ownership of intellectual property is a bad thing.
The DMCA only covers copyrighted material, not material which is in the public domain.
Huh? The DMCA outlaws methods of circumventing copy protection. DeCSS is illegal under the DMCA even if it is used to copy public domain material. When the copyright on a work expires and the item goes in to the public domain, you have the legal right to copy it, redistribute it, whatever. However, under the DMCA, you do not have the legal right to own the tools needed to copy the work. That is precisely the source of a large part of the injustice of the DMCA.
Copyright violation is illegal and should (and will) remain so. However, the DMCA bans information solely on the basis that it can potentially be used to facilitate the violation of copyright, even if it has potential for perfectly legal use. That is unjust and wrong.
The arrest of Dmitry Sklyarov is unjust because the tool he created has perfectly legal uses. Prosecuting people over DeCSS is unjust, because DeCSS has perfectly legal uses.
The DMCA is a misguided and dangerous law that needs to be fought until it is corrected.
2. S/he tells his close circle of cracker friends.
...at which point one of them, wanting to show off their 1337 5ki11z posts to bugraq, and the whole world knows.
3. Somebody outside the cracker community finds out about the hole (usually because they were cracked) and tells the author of the software.
At which point an advisory is made, and the whole world knows.
4. S/he tells a close circle of developer friends.
At which point somebody posts to bugtraq, advisories are made, and the whole world knows.
Imagine an alternate scenario, in which the cracker/hacker from your first step is somebody from CERT, the development team of the server in question, or one of the engineers working on one of the Linux distributions. And imagine that the close circle of friends in step 2 is CERT and the vendor private list. This eliminates steps 3-5, and servers are not being rooted while ignorant sysadmins get shafted by the distribution vendors. In situations like this, it is perfectly safe and quite reasonable to delay the public announcement while the distribution vendors can prepare for it.
In the case where somebody from outside the CERT/distribution vendor circle discovers the vulnerability, the distribution vendors are going to hear about it at the same time as everybody else, and you've got your immediate full public disclosure. But in the case where the people who discover the vulnerability are the same ones who can fix it, then delaying the announcement while a fix is prepared is both responsible and ethical.
CERT had knowledge of the bug, a patch available, and quality assured with that patch... yet they still asked for a delay in publicizing the bug. Why ? The question should not be about RedHat, who acted responsibly, but instead why CERT is causing holdups that allow people in the underground communities more time.
No, Red Hat admitted that they screwed up. The advisory was sent in error, and the person responsible apologized on the vendor private list. They did not act responsibly when publishing their advisory.
And it was not CERT that asked for the delay. The delay is coordinated by all the major distribution vendors to give everybody time to release their updates at once.
There have been a number of posts here claiming that the Linux vendors are being hypocritical by claiming to support full disclosure while maintaining a private list for the coordination of announcements regarding such security issues is this. However, they are missing the point. This list is not against full disclosure in any way. It is simply a way for vendors to coordinate their fixes before the exploit is widely published. At no point are the vendors discouraging the vulnerability's publication. They are merely delaying the announcement so they can coordinate the availability of their updates.
The closed source vendors who are against full disclosure would prefer that the vulnerability is never announced, which would (according to them) allow them to take their time and roll the update into their next service pack release or whatever.
And to the people who suspect some kind of nastiness on Red Hat's part for their early announcement, the individual at Red Hat who claims personal responsibility has already apologized on the private list, and has admitted to erring. The private list has existed for a long time and has worked very well in the past, allowing several vendors to all release fixes at once to a previously unknown vulnerability. It would have worked fine again in this case, except for the mistake by Red Hat.
Yes, that certainly helps, but it can only take you so far. That's really no better than building Apache 2 completely outside the Debian package database and using 'equivs' to create a dummy entry in the package database. You don't get the advantage of easy apt-gettable upgrades, and you don't get security support. You also are at the mercy of build environment changes between distributions.
Being "stuck with whatever software versions Debian freezes on for a couple years", as you say it, is actually a Good Thing(tm).
It can be a good thing, for sure, but at some point there's a tradeoff that must be made between stability and usability. For most of the basic internet services (web, mail, DNS), development has reached a certain point of maturity, and you really don't lose much by running a 2 year old release of sendmail or BIND (provided you have all necessary security updates, which Debian makes easy).
The problem is, though, once you start leaving that realm of the world, upstream development happens at a really fast pace, and Debian's release cycle does not keep up. I often cite GNOME in slink (Debian 2.1) as an example of this problem. Slink shipped with GNOME 0.3, which you may recall was virtually unusable and was certainly not stable. The most frustrating part of that, though, was that by the time slink actually shipped, GNOME 1.0 had been out for months! How can slink be considered stable when the software that comprises it is an old development snapshot?
A more current example may be apache 2. It is still not available for Debian (even in unstable), which leads one to suspect that it won't ship with woody. If it doesn't, then what happens to those users who need apache 2 functionality on mission critical servers? If they need to run unstable to get the software they need, then that defeats the point of stable. If they need to fetch the source and compile apache 2 outside of the Debian package system, then that defeats the point of apt-get.
IMHO, it is unacceptable for Debian to not currently have a stable release that includes PERL 5.6, XFree86 4.x, Linux 2.4.x, etc. What prevented the release manager from proclaiming a freeze 6 or 8 months ago? Newer versions of key packages were available and reasonably well tested at that point, and a 1 or two month freeze would have left us with a released version of Debian that was both stable and reasonably up to date.
One of the key problems, I believe, is that Debian does not use any notion of release goals. This makes it impossible to say for certain when a freeze should happen. It's entirely up to the release manager. Obviously it's not easy to have release goals for a distribution, since much of the software you want to package is not available when drafting the list of goals, but even some sort of vague, general release goals would help to provide focus.
Or maybe the problem is just that nobody actually wants to do QA debugging so they keep putting it off until the release manager gets fed up and stops allowing new features to be added until some bugs are fixed.
I don't know...I've been a Debian user for 5 years and a developer for about a year. I am very frustrated with the pace of the release cycle. Another OS I use regularly (FreeBSD, which I use at work) shares Debian's reputation for quality and stability, but they release at least two versions of their OS each year. They've released three versions since Debian released potato. Why can't we do that?
Every line of code in OpenSSH has been security audited, which explains why the commercial ssh has been found vulnerable to a number of attacks, while OpenSSH has (for the most part) been OK.
If you don't think that all of the commercial implementations have been audited, you are very mistaken. The commercial ssh vendors would not be in business if they did not realize the security benefits of code audits.
Hmm... I don't know if ITS is the future. And good luck getting it to compile. Though I suppose you could get a PDP 10 emulator... Even with the 36 bit emulation it would still probably run faster than the original.
I think you'd find it lacking. Maybe you'd end up a Unix hater, though.
As an active Debian developer you don't read the webpage for Debian? Under the heading Getting Started it notes that latest stable release of Potato, release 3, was released within the lase 12 months. In the last 12 months, release 1 of Potato (2.2) was available on November 14, 2000. Debian 2.2r2 was available on December 3, 2000. 2.2r3, probably the last release in the Potato series was available since April 17, 2001.
Yes, I am aware of the "revision" releases. In fact, r4 is in the works now. However, I don't generally consider these, as they never add functionality. FreeBSD's releases, even the minor ones, add changes beyond just bugfixes.
I guess the race is on. If Debian releases Woody 3.0 by FreeBSD's expected release date of January 15, 2002 for 4.5, then you can feel humiliated.
I think you meant to reverse that. I sure won't feel humiliated if we release 3.0 before FreeBSD makes their next release. I certainly will be humiliated if FreeBSD releases 4.5 before we get 3.0 out the door. I fully expect it to happen, though.
Slashdot Mirror
Exactly. Joe User has no idea what software is, where it comes from, what its limitations are, etc. Computers are magic boxes. If students can handle basic chemistry, physics, and algebra, why can't they handle basic computer science?
Computers are such an integral part of society today, yet knowledge of basic computer science is virtually nonexistant. The way people are trained to interact with computers doesn't even give them the necessary information to know what questions to ask to learn how stuff works. I think that this is very unfortunate, and possibly even detrimental to society as a whole. With the computer industry so thoroughly dominated by a single company, I worry that people will end up unable to think "outside the box".
I think that this wacky new licensing policy by Microsoft is particularly dangerous. Most (public) schools in the U.S. don't have nearly enough money for computer resources. If they have to pay Microsoft for a license even for their Macs or non-Windows PCs, then those machines just got that much more expensive. Maybe too expensive to afford.
Hopefully, instead of pushing non-Windows systems out of schools, this license scheme will actually end up pushing Microsoft out of schools. I don't know that schools will be able to justify that, though, considering how ubiquitious MS is in the "real world".
Anyway, I'm rambling. In any case, I know that I would have a very different perspective on computers if I grew up around Windows instead of BASIC. Personally, I've very glad I had BASIC. Otherwise, I might not have learned how to make a computer do something that it couldn't already do. I think more people need to learn the lessons that BASIC taught me about how to interact with computers.
noah
From what I can gather, NTFS doesn't support symlinks to the same degree as Unix filesystems. It supports "Reparse Points" and "Junction Points", which are described at http://arstechnica.com/paedia/n/ntfs/ntfs5-4.html, but they don't do everything that symlinks do. For example, it doesn't sound like they can point to files, only directories. And I recall reading elsewhere that they must be absolute links, and that relative links aren't supported.
noah
This is a hard link. I do not believe NTFS (even version 5) supports symlinks. IIRC this was going to be the source of some problems for MS, because they provide a POSIX emulation layer, but the latest POSIX spec requires symlink support in filesystems. I once heard an explanation about why it was going to be difficult for MS to provide this functionality given the fundamental structure of NTFS. Sadly, I don't remember it...
noah
It has easily the most confusing documentation and configuration file layout of any VPN-type product i have tried.
Really? I found FreeS/WAN's docs to be amazingly helpful. The config file is certainly a bit different from some of the others out there, but it does work well.
In general IPsec is a great tool for creating VPNs, and since more and more operating systems are including it, it allows for a high level of interoperability (Win2k, Linux, and *BSD, and I think Solaris 8 all include it). The FreeS/WAN people have lots of interop documentation on their site, and as more is written a lot of the current voodoo will be eliminated.
I have recently been doing some interop testing of x.509 certificate-based IPsec authentication between Linux and the KAME implementation (NetBSD, FreeBSD, BDSI), and am writing a document describing the process right now (available at http://web.morgul.net/~frodo/docs/kame+freeswan_in terop.html, though it's not done yet). Certificate-based authentication is great because it eliminates the key distribution problem and makes large-scale deployment a possibility.
noah
To me, this makes mouseless work much easier, as there's no more switching back & forth between virtual desktops, then tab-cycling through windows to get to the right one. Just one keystroke brings up the window I want.
noah
Exactly, but I don't think that will necessarily stop them from passing this stupid law. The problem is that this law will require all kinds of effort on the part of software and hardware designers, yet won't change the fact that bits are just bits and there will always be a way to move them around.
noah
Easy. Linux won't meet the requirements for DRM that the SSSCA requires. If any Linux distributor decided to implement DRM, the open source nature of the software would allow the user to easily disable or remove it. If you think the SSSCA will allow for easily bypassed DRM, you don't understand what they're going for.
Open source software allows users and developers to take advantage of the power of the tools available to them. This is fundamentally at odds with the SSSCA, which seeks fundamentally to limit the power of those tools.
noah
No, it was Stanford that gave up their class A. What were they thinking? MIT still has ungodly amounts of address space. We have net 18 (18.0.0.0/8), plus random assorted /16s (128.52, for example, is the AI lab). There are a couple others.
The thing is, though, there's a whole lot of "reserved" address space out there. The IPv4 address space shortage is partially artificial. In some ways this is to preven the world from grinding to a screeching halt where there really are no more IPv4 addresses. Another is that maybe it will put pressure on people to be conservative with address allocation, which might make the shortage less pressing. Maybe it will also help to speed the deployment of IPv6.
Most OS vendors are already supportind IPv6 out of the box. WinXP, for example, can be set up as an autoconfiguring IPv6 host very easily (ipv6/install at a command prompt, IIRC). The BSDs support it very well, as do many Linux vendors. I think that it won't be long until IPv6 communication on the internet is very widespread. I don't, however, think the whole internet will be IPv6 any time soon.
noah
This is absolutely correct, and a very important thing to consider. People don't realize that their every move is on some camera somewhere. By making the output from these cameras available, people can see what others are seeing. They are more aware of the fact that they're on camera.
For a much more articulate description of why this is a good thing, please read David Brin's The Transparent Society. A good exerpt can be found at wired.com.
noah
Typically, major version increments are forbidden. In some cases, exceptions must be made (e.g. a package is rewritten from scratch to correct security problems).
As I said before, there are no known security problems with the current version of OpenSSH 1. There have been in the past, but they've been fixed. It's not that there is no example code, it's that there are no known potentially exploitable security issues in the current OpenSSH shipped with Debian.
noah
"* Recompile. Due to strange interactions with libc6, functions weren't interpreted, and the package was practically unusable. Closes: #108924."
noah
Still, though, version 2 of the SSH protocol is better, and building updated OpenSSH packages for potato is not difficult. The 'source' command in apt-get is very helpful here.
noah
OK, but the point of my post is still valid. Even after copyright expires, the law must be broken in order for one to get the tools that allow you to circumvent access controls, even though you do have the legal right to what's on the other side of the access controls. Of course, the law need not be broken if you're on of the very few people in the world capable of cracking CSS without outside information.
The DMCA cases really sound like the lawmakers are trying to reclassify fair use rights as fair use privilages, privilages that we can't complain about losing when they're taken away.
Maybe it is possible that, with the advent of widespread digital communications, copyright law really is obsolete and the DMCA is just a flailing, panicked attempt to prop it up for a bit longer. Maybe copyright can't work as intended anymore... I just wish all this junk would go away so I can spend my time thinking about more interesting problems.
noah
Yes.
Yes, you're right. However, it's illegal to posess the tools needed to circumvent the access controls on a work, even after the copyright expires. So whether or not it's legal to circumvent the copy protection is completely irrelevant. You can't legally do it anyway.
noah
That's precisely the problem. "...the work is primarily created for copyright circumvention". Aside from the original author of the work, who's to say what the primary purpose of a work is? Hell, the primary purpose of Dr. Felten's work is to merely prove that SDMI is a flawed approach to preventing copyright. Yet RIAA is (apparently) going to succeed at using the DMCA to prevent him from presenting that work. Surely you don't think that the primary purpose of his research is to facilitate copyright infringement.
Oh please. DeCSS was created to circumvent copyright. It was marketed to circumvent copyright. Those legitimate uses are merely incidental. This is not only the ruling the courts made, it is the truth.
Well, if you say so. I suspect, however, that there are a great deal many more people using DeCSS for purely legitimate purposes than for copyright infringement. How many Linux DVD player projects depend completely on its existance? I can think of at least 4 or 5, but I can't name any DVD copying software for any OS that depends on DeCSS.
If I might ask, what do you believe should exist in place of copyright law? Do you believe that all intellectual property should belong to the public domain? I agree that copyright law has major problems (especially after the Sonny Bono Copyright Extension), but I am not sure that legal protection of ownership of intellectual property is a bad thing.
noah
Huh? The DMCA outlaws methods of circumventing copy protection. DeCSS is illegal under the DMCA even if it is used to copy public domain material. When the copyright on a work expires and the item goes in to the public domain, you have the legal right to copy it, redistribute it, whatever. However, under the DMCA, you do not have the legal right to own the tools needed to copy the work. That is precisely the source of a large part of the injustice of the DMCA.
Copyright violation is illegal and should (and will) remain so. However, the DMCA bans information solely on the basis that it can potentially be used to facilitate the violation of copyright, even if it has potential for perfectly legal use. That is unjust and wrong.
The arrest of Dmitry Sklyarov is unjust because the tool he created has perfectly legal uses. Prosecuting people over DeCSS is unjust, because DeCSS has perfectly legal uses.
The DMCA is a misguided and dangerous law that needs to be fought until it is corrected.
noah
3. Somebody outside the cracker community finds out about the hole (usually because they were cracked) and tells the author of the software.
At which point an advisory is made, and the whole world knows.
4. S/he tells a close circle of developer friends.
At which point somebody posts to bugtraq, advisories are made, and the whole world knows.
Imagine an alternate scenario, in which the cracker/hacker from your first step is somebody from CERT, the development team of the server in question, or one of the engineers working on one of the Linux distributions. And imagine that the close circle of friends in step 2 is CERT and the vendor private list. This eliminates steps 3-5, and servers are not being rooted while ignorant sysadmins get shafted by the distribution vendors. In situations like this, it is perfectly safe and quite reasonable to delay the public announcement while the distribution vendors can prepare for it.
In the case where somebody from outside the CERT/distribution vendor circle discovers the vulnerability, the distribution vendors are going to hear about it at the same time as everybody else, and you've got your immediate full public disclosure. But in the case where the people who discover the vulnerability are the same ones who can fix it, then delaying the announcement while a fix is prepared is both responsible and ethical.
noah
No, Red Hat admitted that they screwed up. The advisory was sent in error, and the person responsible apologized on the vendor private list. They did not act responsibly when publishing their advisory.
And it was not CERT that asked for the delay. The delay is coordinated by all the major distribution vendors to give everybody time to release their updates at once.
noah
Proftpd hardly has a stellar security record of its own. Google will quickly verify that statement.
noah
The closed source vendors who are against full disclosure would prefer that the vulnerability is never announced, which would (according to them) allow them to take their time and roll the update into their next service pack release or whatever.
And to the people who suspect some kind of nastiness on Red Hat's part for their early announcement, the individual at Red Hat who claims personal responsibility has already apologized on the private list, and has admitted to erring. The private list has existed for a long time and has worked very well in the past, allowing several vendors to all release fixes at once to a previously unknown vulnerability. It would have worked fine again in this case, except for the mistake by Red Hat.
noah
apt-get -b source apache2
dpkg -i *.deb
Yes, that certainly helps, but it can only take you so far. That's really no better than building Apache 2 completely outside the Debian package database and using 'equivs' to create a dummy entry in the package database. You don't get the advantage of easy apt-gettable upgrades, and you don't get security support. You also are at the mercy of build environment changes between distributions.
noah
It can be a good thing, for sure, but at some point there's a tradeoff that must be made between stability and usability. For most of the basic internet services (web, mail, DNS), development has reached a certain point of maturity, and you really don't lose much by running a 2 year old release of sendmail or BIND (provided you have all necessary security updates, which Debian makes easy).
The problem is, though, once you start leaving that realm of the world, upstream development happens at a really fast pace, and Debian's release cycle does not keep up. I often cite GNOME in slink (Debian 2.1) as an example of this problem. Slink shipped with GNOME 0.3, which you may recall was virtually unusable and was certainly not stable. The most frustrating part of that, though, was that by the time slink actually shipped, GNOME 1.0 had been out for months! How can slink be considered stable when the software that comprises it is an old development snapshot?
A more current example may be apache 2. It is still not available for Debian (even in unstable), which leads one to suspect that it won't ship with woody. If it doesn't, then what happens to those users who need apache 2 functionality on mission critical servers? If they need to run unstable to get the software they need, then that defeats the point of stable. If they need to fetch the source and compile apache 2 outside of the Debian package system, then that defeats the point of apt-get.
IMHO, it is unacceptable for Debian to not currently have a stable release that includes PERL 5.6, XFree86 4.x, Linux 2.4.x, etc. What prevented the release manager from proclaiming a freeze 6 or 8 months ago? Newer versions of key packages were available and reasonably well tested at that point, and a 1 or two month freeze would have left us with a released version of Debian that was both stable and reasonably up to date.
One of the key problems, I believe, is that Debian does not use any notion of release goals. This makes it impossible to say for certain when a freeze should happen. It's entirely up to the release manager. Obviously it's not easy to have release goals for a distribution, since much of the software you want to package is not available when drafting the list of goals, but even some sort of vague, general release goals would help to provide focus.
Or maybe the problem is just that nobody actually wants to do QA debugging so they keep putting it off until the release manager gets fed up and stops allowing new features to be added until some bugs are fixed.
I don't know...I've been a Debian user for 5 years and a developer for about a year. I am very frustrated with the pace of the release cycle. Another OS I use regularly (FreeBSD, which I use at work) shares Debian's reputation for quality and stability, but they release at least two versions of their OS each year. They've released three versions since Debian released potato. Why can't we do that?
noah
If you don't think that all of the commercial implementations have been audited, you are very mistaken. The commercial ssh vendors would not be in business if they did not realize the security benefits of code audits.
noah
I think you'd find it lacking. Maybe you'd end up a Unix hater, though.
noah
Yes, I am aware of the "revision" releases. In fact, r4 is in the works now. However, I don't generally consider these, as they never add functionality. FreeBSD's releases, even the minor ones, add changes beyond just bugfixes.
I guess the race is on. If Debian releases Woody 3.0 by FreeBSD's expected release date of January 15, 2002 for 4.5, then you can feel humiliated.
I think you meant to reverse that. I sure won't feel humiliated if we release 3.0 before FreeBSD makes their next release. I certainly will be humiliated if FreeBSD releases 4.5 before we get 3.0 out the door. I fully expect it to happen, though.
noah