Slashdot Mirror

I just don't believe it...

(Professor Bernstein, in an e-mail reply to a question, did mention he was going to update DJBFFT, but this does not appear to have happened. In all probability he lacks the time, but that doesn't solve the problem of needing high-power FFT software. FFTW, although slightly better on updates, isn't massively better. What is needed is for someone to start a project with the goal of writing code as fast as DJBFFT, as generic as FFTW, and as active as LinuxBIOS or the Linux Kernel in terms of getting new code out there.)

FFTW is the 'Fastest Fourier Transform in the West', a cute name for the work of a number of graduate students who use several techniques to turn the FFT from 'Numerical Recipes in C' into a freaking speed daemon. ... but not as fast as djbfft, right? (I'm asking rather than telling, as I have very little FFT experience and am intrigued to know)

For example, after purchasing a copy of Microsoft Windows NT 4.0 Workstation---which is a poorly tuned version of NT 4.0 Server, minus a few utilities---you can back it up, apply a small patch that fixes the tuning, and run the result.

Microsoft hates this. Of course, Microsoft could restrict your rights by demanding that you sign a contract before you get a copy of Windows NT, but this would not do wonders for Windows sales.

So Microsoft puts a ``license'' on all of its software and pretends that you don't have the right to use the software unless you agree to the ``license.'' You can't patch Windows without their permission, according to the license; you can't use NT Workstation for more than 10 simultaneous connections; you must give Microsoft your first-born son. (Or something like that.)

The problem with Microsoft's license is that it's unenforceable. You can simply ignore it. Microsoft can't win a copyright infringement lawsuit: you own the software that Microsoft sold you, and Congress gave you the right to use it.

D. J. Bernstein (of djbdns fame/infamy) has some words about this very issue (he is at University of Illinois at Chicago): http://cr.yp.to/uic.html

Indeed, country level TLDs are very strictly enforced. Espcially ones like Christmas Island and Tobago/

Oh, wait. Country TLD's are abused just like any other TLD.

... and they're recommended by DJB.

http://cr.yp.to/djbdns/dot-com.html

Actually, QMail is the one designed with security in mind. As far as I'm aware it's never had any vulnerabilities. See security guarantee.

That has more to do with DJBDNS's license than its performance. DJBDNS is not GPL, and is certainly not BSD licensed.

See here

His software isn't remotely public domain. http://cr.yp.to/distributors.html gives his licensing details, which make it quite clear he's an idiot.

having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'

Anyone want to discuss how DNS Cache addresses this? AFAIK this is a pretty "safe" way to provide DNS to at least a small sized network - but that's all I run it on. Comments, concerns, advice?

That's why you run djbdns -- by default it's closed to recursive queries.

That's not the problem.

The problem with IP6 is that it isn't backwards compatible with IPv4.

IPv6 will *never* happen.

http://cr.yp.to/djbdns/ipv6mess.html

Read about SYN Cookies. This is a method of avoiding SYN DOS attacks that has already been implemented in Linux (and probably elsewhere) for a while. I think SCTP just integrates the same concept into the official protocol specification. Once the SCTP server sends the INIT-ACK, it doesn't have to keep track of that association until the client sends a COOKIE-ECHO.

Unlikely. DJB is on sabbatical right now, and I think UIC has "spring", "summer" and "fall" terms, not "winter" which would indicate a school that uses the quarter system.

FWIW, I believe all 3 of your assertions about his UNIX security assignment are incorrect. The assignment didn't look at all impossible. Consider *all* the software on sourceforge. 10 bugs is not a lot to find over an academic term, given such a mass to work off. It does not constitute "severe ramifications" or "callous disrespect" (especially in an elective course) to lay out expectations for students and then grade them according to the standards you set at the beginning of the term.

Two questions: When copyright expires on a piece of software, am I still bound by the EULA (assume for a moment that the EULA is a valid contract)? I suppose I could read the EULA to search for an expiration... And second, is there any commercially available proprietary software that does not include a EULA (other than the default copyright restrictions)?

Wrong. The EULA is meaningless. The GPL is not an EULA, it's some extra rights above and beyond the rights granted to you by copyright law. Copyright law forbids you from distributing copies of software, but the GPL allows it under certain conditions. Hence, if you don't accept the GPL, you simply can't distribue the software -- which you couldn't have done anyway.

Apple's EULA is unenforceable because by buying the CD, you can do whatever you want with the software. You don't need any additional rights above and beyond copyright law to allow you to run the program. So if you disagree with the EULA, fine... you lose nothing.

From http://cr.yp.to/softwarelaw.html:

> In the United States, once you own a copy of a program, you can back it up, compile it, run it, and even modify it as necessary, without permission from the copyright holder. See 17 USC 117.

It should be noted that no application is secure enough

Except qmail.

Meanwhile the rest of the world thinks that they have to choose between functionality and security and manage to get neither particularly well.

I'll just point everyone to DJB:
    http://cr.yp.to/djbdns/ipv6mess.html

He pretty much covers most of it. IPv6 is dead on the public Internet long before it started. I knew this as soon as I called up MCI/WorldCom last year to ask if they had any IPv6 address space to add to our few class-C's and they laughed at me. If the folks who run half the Internet aren't ready for it, why would we be?

-M

I suggest using the QTDIR variable to find your default location, and the linker to find your libraries

Demanding that my system become less functional because you don't know better than to use hard-coded pathnames is ridiculous.

/package reuses the filesystem as the database. It provides you with all the package management features you get from traditional package managers, as well as many features they don't provide; for example, adding new files to a package, or declaring that some existing files form a package. A ``central database'' is neither necessary nor desireable.

/package reuses the filesystem as the database. It provides you with all the package management features you get from traditional package managers, as well as many features they don't provide; for example, adding new files to a package, or declaring that some existing files form a package. A ``central database'' is neither necessary nor desireable.

Maybe you want something like tcpclient and company, by DJB.

http://cr.yp.to/ucspi-tcp.html

Any program that requires QT to live in /usr/local/qt3, is *broken* in the first place.

If you write your programs to #include , not "/usr/local/qt3", and to have the libqt-mt.so.3 SONAME in DT_NEEDED, rather than (ugh) hard-coding in /usr/local/lib/qt3/lib/libqt.so.3, and so on, then you don't have to know where QT's files actually are.

If you are curious, you can always find out with dpkg --listfiles libqt3-mt.

If the packages dumped all their stuff in /usr/local/$package, you would have to maintain an ever-growing list of directories in which to search for shared libraries, headers, binaries, man pages, etc.

Something else that you'd lose the ability to do is to share out /usr/share, to make *all* the arch-independant, data in an installation available to machines on a network.

/usr/share/qt3 -> /usr/local/lib/qt3/share

Any program that requires QT to live in /usr/local/qt3, is *broken* in the first place.

If you write your programs to #include , not "/usr/local/qt3", and to have the libqt-mt.so.3 SONAME in DT_NEEDED, rather than (ugh) hard-coding in /usr/local/lib/qt3/lib/libqt.so.3, and so on, then you don't have to know where QT's files actually are.

If you are curious, you can always find out with dpkg --listfiles libqt3-mt.

If the packages dumped all their stuff in /usr/local/$package, you would have to maintain an ever-growing list of directories in which to search for shared libraries, headers, binaries, man pages, etc.

Something else that you'd lose the ability to do is to share out /usr/share, to make *all* the arch-independant, data in an installation available to machines on a network.

/usr/share/qt3 -> /usr/local/lib/qt3/share

Breaking cross-platform compatibility, as Debian does, for the sake of cross-package similarity is a horrible idea.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard

You couldn't be more wrong when you say Debian ``compromises'' to achieve cross-platform compatibility. In fact, they want everyone to conform to their world view; this is an uphill battle and it will never work. Different upstream authors do things differently with their packages, and they're not all going to suddenly change because Debian and the FHS are yelling at them that they're packages are ``broken.'' They choose layouts that reduce the total effort required by them to support all platforms.

But if you're an upstream maintainer, Debian will change your package's interface downstream as they see fit and make it incompatible with your upstream version. Now all the programs which depend on your upstream interface will break on Debian. So Debian will fix those programs, too, if they happen to package them. But if they don't, your users are in for headaches.

Don't get me wrong, Debian is a fantastic operating system. But there would be so many fewer headaches for users if they attempted to ``play nice'' with other systems, rather than saying ``It's the Debian way or the high way!''

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard

You couldn't be more wrong when you say Debian ``compromises'' to achieve cross-platform compatibility. In fact, they want everyone to conform to their world view; this is an uphill battle and it will never work. Different upstream authors do things differently with their packages, and they're not all going to suddenly change because Debian and the FHS are yelling at them that they're packages are ``broken.'' They choose layouts that reduce the total effort required by them to support all platforms.

But if you're an upstream maintainer, Debian will change your package's interface downstream as they see fit and make it incompatible with your upstream version. Now all the programs which depend on your upstream interface will break on Debian. So Debian will fix those programs, too, if they happen to package them. But if they don't, your users are in for headaches.

Don't get me wrong, Debian is a fantastic operating system. But there would be so many fewer headaches for users if they attempted to ``play nice'' with other systems, rather than saying ``It's the Debian way or the high way!''

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard

You couldn't be more wrong when you say Debian ``compromises'' to achieve cross-platform compatibility. In fact, they want everyone to conform to their world view; this is an uphill battle and it will never work. Different upstream authors do things differently with their packages, and they're not all going to suddenly change because Debian and the FHS are yelling at them that they're packages are ``broken.'' They choose layouts that reduce the total effort required by them to support all platforms.

But if you're an upstream maintainer, Debian will change your package's interface downstream as they see fit and make it incompatible with your upstream version. Now all the programs which depend on your upstream interface will break on Debian. So Debian will fix those programs, too, if they happen to package them. But if they don't, your users are in for headaches.

Don't get me wrong, Debian is a fantastic operating system. But there would be so many fewer headaches for users if they attempted to ``play nice'' with other systems, rather than saying ``It's the Debian way or the high way!''

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.

No, the FHS specifically prevents cross-platform compatibility. For example, if a package is installed ``locally'' on one system it will have a different interface than if it installed as part of ``the system'' on another. For example, how do we find libssl.so on an FHS-compliant system? Is it /usr/lib/libssl.so or /usr/local/lib/libssl.so, or even /opt/openssl/lib/libssl.so? The FHS ensures we will never have a simple, consistent name, like we would have if the package author madated it to be /package/host/openssl.org/openssl/libssl.so.

Now remove it and install the various Debian packages which make up Qt. Notice how everything is different---binaries are in /usr/bin, libraries are in /usr/share/qt3/lib, headers are in /usr/include/qt3. Try accessing /usr/local/qt/include/qt.h: you can't.

I've administered systems of different ages and for different purposes, and yes, it is frustrating. But that's because package authors tend to choose poor interfaces, and system integrators then modify these interfaces, making things worse. The FHS is not a solution because it mandates different interfaces for the same package, depending on whether it is ``local'' or part of ``the system.'' I'd love it if all packages used a consistent interface which provided global names that don't change, but that's a decision for package authors, not system integrators.

Perhaps you are right that some distributions change things more than Debian. But my main point is that Debian mandates these types of changes in their policy.

Now remove it and install the various Debian packages which make up Qt. Notice how everything is different---binaries are in /usr/bin, libraries are in /usr/share/qt3/lib, headers are in /usr/include/qt3. Try accessing /usr/local/qt/include/qt.h: you can't.

I've administered systems of different ages and for different purposes, and yes, it is frustrating. But that's because package authors tend to choose poor interfaces, and system integrators then modify these interfaces, making things worse. The FHS is not a solution because it mandates different interfaces for the same package, depending on whether it is ``local'' or part of ``the system.'' I'd love it if all packages used a consistent interface which provided global names that don't change, but that's a decision for package authors, not system integrators.

Perhaps you are right that some distributions change things more than Debian. But my main point is that Debian mandates these types of changes in their policy.

Cross-platform compatibility is essential. If the upstream Apache maintainers say Apache can be stopped with apachectl stop, Debian should damn well support this interface. I don't care if they provide /etc/init.d/httpd stop in addition, but they should support the standard interface. This makes life infinitely simpler for people who deal with many different systems---they don't have to keep relearning things. It also makes things simpler for people offering support to Apache users.

The tremendous benefits of cross-platform compatibility come from a package's interface being exactly the same on every system. It is a relatively minor benefit for different packages to have similar interfaces. Breaking cross-platform compatibility, as Debian does, for the sake of cross-package similarity is a horrible idea.

I should point out that I'm picking on Debian here because they are especially bad about this, but almost every major Linux distribution is guilty of unncessarily violating cross-platform compatibility in some way.

At a minimum, people should use alternative dns client libraries. After the libresolv security disaster, the djbdns client library was released as Public Domain which is arguably the most generous license possible (contrast with djb's highly annoying license for his other fine software--see NOTE at end of post).

If you are not familiar with djbdns, it is a BIND alternative that is simpler to manage and much more secure.

I've been using djbdns for a couple years and there hasn't been any exploits published about it. In fact, there's even a cash reward to anyone who finds a security hole in djbdns:

http://cr.yp.to/djbdns/guarantee.html

NOTE: The author of djbdns (and qmail, ucspi-tcp, ...) is D. J. Bernstein (djb). He offers a cash reward for people who find security holes in his software. He is generally well-respected for the quality of his software and equally annoying for not allowing modified versions of his software to be distributed (which is why people distribute modifications via patches). However, high-quality patches like chkuser 2.0 (for qmail) do exist and the annoying license hasn't been able to prevent steady progress of features/enhancements being added to his software via open source.

Interestingly, he had a "disagreement" with the US Government in court over cryptography laws and appears to have won (for now).

At a minimum, people should use alternative dns client libraries. After the libresolv security disaster, the djbdns client library was released as Public Domain which is arguably the most generous license possible (contrast with djb's highly annoying license for his other fine software--see NOTE at end of post).

If you are not familiar with djbdns, it is a BIND alternative that is simpler to manage and much more secure.

I've been using djbdns for a couple years and there hasn't been any exploits published about it. In fact, there's even a cash reward to anyone who finds a security hole in djbdns:

http://cr.yp.to/djbdns/guarantee.html

NOTE: The author of djbdns (and qmail, ucspi-tcp, ...) is D. J. Bernstein (djb). He offers a cash reward for people who find security holes in his software. He is generally well-respected for the quality of his software and equally annoying for not allowing modified versions of his software to be distributed (which is why people distribute modifications via patches). However, high-quality patches like chkuser 2.0 (for qmail) do exist and the annoying license hasn't been able to prevent steady progress of features/enhancements being added to his software via open source.

Interestingly, he had a "disagreement" with the US Government in court over cryptography laws and appears to have won (for now).

At a minimum, people should use alternative dns client libraries. After the libresolv security disaster, the djbdns client library was released as Public Domain which is arguably the most generous license possible (contrast with djb's highly annoying license for his other fine software--see NOTE at end of post).

If you are not familiar with djbdns, it is a BIND alternative that is simpler to manage and much more secure.

I've been using djbdns for a couple years and there hasn't been any exploits published about it. In fact, there's even a cash reward to anyone who finds a security hole in djbdns:

http://cr.yp.to/djbdns/guarantee.html

NOTE: The author of djbdns (and qmail, ucspi-tcp, ...) is D. J. Bernstein (djb). He offers a cash reward for people who find security holes in his software. He is generally well-respected for the quality of his software and equally annoying for not allowing modified versions of his software to be distributed (which is why people distribute modifications via patches). However, high-quality patches like chkuser 2.0 (for qmail) do exist and the annoying license hasn't been able to prevent steady progress of features/enhancements being added to his software via open source.

Interestingly, he had a "disagreement" with the US Government in court over cryptography laws and appears to have won (for now).

At a minimum, people should use alternative dns client libraries. After the libresolv security disaster, the djbdns client library was released as Public Domain which is arguably the most generous license possible (contrast with djb's highly annoying license for his other fine software--see NOTE at end of post).

If you are not familiar with djbdns, it is a BIND alternative that is simpler to manage and much more secure.

I've been using djbdns for a couple years and there hasn't been any exploits published about it. In fact, there's even a cash reward to anyone who finds a security hole in djbdns:

http://cr.yp.to/djbdns/guarantee.html

NOTE: The author of djbdns (and qmail, ucspi-tcp, ...) is D. J. Bernstein (djb). He offers a cash reward for people who find security holes in his software. He is generally well-respected for the quality of his software and equally annoying for not allowing modified versions of his software to be distributed (which is why people distribute modifications via patches). However, high-quality patches like chkuser 2.0 (for qmail) do exist and the annoying license hasn't been able to prevent steady progress of features/enhancements being added to his software via open source.

Interestingly, he had a "disagreement" with the US Government in court over cryptography laws and appears to have won (for now).

You make a very good case for using maildir.

For gods sake, if you're not writing an operating system you have no business using C. Read me lips: YOU CAN'T WRITE SECURE C. Not now, not after 20 thousand hours of training, not ever.

A few points....

Microsoft never claimed any of the Win9x series of OS's to be secure. They specifically said that if you wanted security in their products to use NT. There was no security model at all in the 9x series of OS's, so 'security' as we know it today was not possible.

It would be nice if everyone was so forward thinking, but hardly anyone is. With Windows 95, Microsoft got caught with their pants down in regards to the internet and security, as right around the time windows 95 was released, internet usage started to explode. The first ever computer worm, "morris" afected unix machines running sendmail, and it took down virtually every unix machine on the 'internet' back when it was accidentally released. The scenario that led to morris was very similar to the one that led to all of the security problems with Windows. People just weren't very concerned about security back then and didn't see the potential security pitfalls that connecting a bunch of computers together could bring.

The comparison of the age of windows the age of linux isn't very fair. Linux has been a 32 bit operating system since it's birth in 1991 an it's overall design (a unix type OS) has not changed. Windows started being a true 32 bit OS with NT 4.0 which was released around 94 I believe, ad has absolutely nothng to do, in regards to it's core design, with any of the Windows 9x versions. All of your experience with Windows is with the 9x series which sole purpose was to transition customers over from a DOS based OS's to NT based OSs without breaking compatibility with legacy DOS programs. Obviosuly the transition was a rough one for many, for history has shown (read: Apple's transition from the Apple IIe to the Macintosh) that completely abandoning legacy technology and trying to force your customers straight into a new and improved technology without providing any legacy support is market suicide.

The reason XP was shipped making users admin by default was not because Microsoft didn't understand the security implications of it. It was a backwards compatibitly issue. Windows had a massive amount of old software written for Windows 95 and 98 and breaking compatibility withn them would be very very bad. Windows XP fully supports the installation of programs by regular users...*IF* the program is written with that in mind. When Microsoft shipped Windows 2000 and then XP, they tried to get windows developers to start coding their programs with security model in mind, but for the most part programmers ignored Microsoft's advice and continued to code their programs assuming that the end users would have admin rights.

"It wouldn't be too hard to make the OS tell you if the program's trying to change important system files, would it? "

No it's not hard at all. Windows has done it for ages by saying "access denied". All joking aside, Windows has had the capability of prompting you for admin rights when a properly written installer is launched under a non admin account. The problem is developers don't write their installers properly to take advanatge of this feature. I have the distinct feeling you're thinking of Mac OSX's ability to prompt for admin password when users try to install something. The reason this works so well in Mac OSX has tiny amount of software avaiable for it compared to Windows, and thus a much smaller pool of developers. Getting a group developers to all do something is akin to herding cats. Apple's "herd" is a hundred time smaller than Microsoft's "herd".

"Sorry, but Google says otherwise. First item on the page - New Version of MyDoom Worm in Zero-Day Attack."

This is not what I was talking about when I said "worm". I'm talking about things that replicate without user input. Something that spreads via an Intenet Explorer exploit requires user to go to a specially crafted web page to get infected. It's still bad, but IE has a very long history of being repeatedly exploited, much like sendmail in the 80's

The Directive will be rubber-stamped by the Council. It will be challenged in several national courts and possibly the European Court of Human Rights, for it breaks article 8 of this convention quite flagrantly.

But there appears to be no process for overturning the directive. EU directives override national law. This is a great success for the UK government which tried and failed to have this law passed in the UK.

Ironically, a report by the Commission just 4 years ago on the Echelon surveillance system stated quite clearly that "Only in a 'police state' is the unrestricted interception of
communications permitted by government authorities."

The EU is now officially a 'police state', by the Commission's own words.

http://cr.yp.to/djbdns/ipv6mess.html

Do we really have to throw this much money into the volcano?

Bottom line: Most people want glitz more than security. Case in point: Publicfile, DJB's web and FTP server. No one uses Publicfile, even though it has a far better security history than, say, Apache (I'm not saying Apache is insecure; I'm saying that Apache has had more security patches in its history than Publicfile). Why is this? Because web designers want high-performance dynamic content in several different programming languages. They want glitz more than security.

The only reason why djbdns and Qmail caught on is because they were reimplementations of internet protocols which were largely unchanged for over 15 years, and the main implementation of these protocols were grossly insecure at the time (just as MSIE security problems are bad enough that about 15% of the market is seriously looking at Firefox--the same marketshare Qmail got and djbdns has).

Security is not as important as you think it is; people generally conisder other features more important than security.

Bottom line: Most people want glitz more than security. Case in point: Publicfile, DJB's web and FTP server. No one uses Publicfile, even though it has a far better security history than, say, Apache (I'm not saying Apache is insecure; I'm saying that Apache has had more security patches in its history than Publicfile). Why is this? Because web designers want high-performance dynamic content in several different programming languages. They want glitz more than security.

The only reason why djbdns and Qmail caught on is because they were reimplementations of internet protocols which were largely unchanged for over 15 years, and the main implementation of these protocols were grossly insecure at the time (just as MSIE security problems are bad enough that about 15% of the market is seriously looking at Firefox--the same marketshare Qmail got and djbdns has).

Security is not as important as you think it is; people generally conisder other features more important than security.

Bottom line: Most people want glitz more than security. Case in point: Publicfile, DJB's web and FTP server. No one uses Publicfile, even though it has a far better security history than, say, Apache (I'm not saying Apache is insecure; I'm saying that Apache has had more security patches in its history than Publicfile). Why is this? Because web designers want high-performance dynamic content in several different programming languages. They want glitz more than security.

The only reason why djbdns and Qmail caught on is because they were reimplementations of internet protocols which were largely unchanged for over 15 years, and the main implementation of these protocols were grossly insecure at the time (just as MSIE security problems are bad enough that about 15% of the market is seriously looking at Firefox--the same marketshare Qmail got and djbdns has).

Security is not as important as you think it is; people generally conisder other features more important than security.

Bottom line: Most people want glitz more than security. Case in point: Publicfile, DJB's web and FTP server. No one uses Publicfile, even though it has a far better security history than, say, Apache (I'm not saying Apache is insecure; I'm saying that Apache has had more security patches in its history than Publicfile). Why is this? Because web designers want high-performance dynamic content in several different programming languages. They want glitz more than security.

The only reason why djbdns and Qmail caught on is because they were reimplementations of internet protocols which were largely unchanged for over 15 years, and the main implementation of these protocols were grossly insecure at the time (just as MSIE security problems are bad enough that about 15% of the market is seriously looking at Firefox--the same marketshare Qmail got and djbdns has).

Security is not as important as you think it is; people generally conisder other features more important than security.

Look at the abundance of well built DNS daemons in place.... PowerDNS, Daniel Bernsteins djbDNS, MaraDNS. Hell djbDNS has an ongoing cash prize to people who can find security vulnerabilities in the latest production version. Still though, people stick with microsoft dns and bind.