Slashdot Mirror

DNS cache poison can be effectively stopped by using the correct DNS caching program. Basically, it is important to use a strong psudo-random number generator to determine the DNS query ID. Ideally, we have the same psudo-random number generator determine the source port of the DNS query.

To the extent of my knowledge, only two recursive DNS servers have this level of DNS poison protection: DjbDNS' dnscache and MaraDNS.

It is also important to have bailwick protection. Basically, the recursive DNS server needs to look at a DNS reply, and filter out any answers not in the bailwick. Older DNS servers (and possibly poorly written embedded DNS caches and recursive servers) will get a reply like "www.paypal.com has the ip 10.1.2.3" to the question "what is the ip for www.phisherscum.com?", and incorrectly cache the data for www.paypal.com instead of saying "I didn't ask for paypal.com's ip, so I'll ignore this data as being out of bailwick".

Additionally, it improves security to restrict which IP addresses are allowed to make remote DNS queries. This is best done at the firewall level (don't allow any UDP connections to port 53 from the internet at large unless you have some domains hosted by the machine in question). This stops malicious servers sending a large number of requests to your dns server for www.paypal.com, and a number of bogus answers "www.paypal.com has the IP of some phishing site in China; remember this until 2007", until one of the answers looks valid and fools your DNS server.

In summary, by using a secuirty aware DNS resolver, you can minimize, if not eliminate the chances of being vulnerable to bogus DNS data.

BSD insists on putting ``ports'' under /usr/local, while Linux insists on not using /usr/local for anything that comes with the system. Both approaches produce failures for the users: programs not starting, for example. More importantly, the lack of cross-platform compatibility imposes tremendous costs on the UNIX community.

BSD insists on putting ``ports'' under /usr/local, while Linux insists on not using /usr/local for anything that comes with the system. Both approaches produce failures for the users: programs not starting, for example. More importantly, the lack of cross-platform compatibility imposes tremendous costs on the UNIX community.

Perhaps does the gov't know of a "quick" way to do large prime factorization unknown to the rest of us? With RSA resting so heavily on big primes, it would be uniquely vulnerable to something like a new way to do factorization.

Actually factorization has been looking a little weak for the last couple of years. There hasn't been any big breakthrough, and 1024-bit (and up) RSA isn't exactly broken right now, but there have been a steady number of papers that have offered various improvements to the basic Number Field Sieve algorithm (such as Dan Bernstein's facorization circuit) that it is beginning to look as if it is merely a matter of time before at least 1024-but RSA is considered insecure.

Certainly if you have enough compute power the present NFS with improvements will be good enough to break RSA keys out. The NSA is not exactly lacking in potentially dedicated compute power.

Jedidiah.

"C has a really crappy track record of being secure"

C doesn't kill people, sloppy programmers kill people.

C is just a language; it is neither secure nor insecure. It depends on how lazy the programmer using it is. I'm thrilled there's a thing called C# that helps sloppy programmers. Warn me if anybody writes an OS in that bloated pig.

But C by and of itself dosn't mean code is insecure.

"C has a really crappy track record of being secure"

C doesn't kill people, sloppy programmers kill people.

C is just a language; it is neither secure nor insecure. It depends on how lazy the programmer using it is. I'm thrilled there's a thing called C# that helps sloppy programmers. Warn me if anybody writes an OS in that bloated pig.

But C by and of itself dosn't mean code is insecure.

Agreed. DJB's Poly1305-AES might be worth mentioning here (?).

Not quite corrent; if you give me a copy of a work, I can back it up, compile it, modify it, otherwise tinker with it, and so on. See http://cr.yp.to/softwarelaw.html for more info. The only thing I can't do is distribute it, or works derived from it.

This is the difference between click-through bullshit EULAs and licenses such as the GPL. EULAs try to take away your rights; the GPL grants you additional rights: mainly the right to redistribute the original works, and the right to distribute derived works, as long as you license such works under the GPL.

(This is not meant as a comment on the security of HMAC-SHA-1.)

Incidentally, there's no obstacle to Firefox adding IDNC3 support. If the user types a non-ASCII URL, Firefox can't simultaneously treat it as both broken-IDN and IDNC3, but the whole discussion here is prompted by Firefox turning off broken-IDN by default.

D. J. Bernstein (djbdns, qmail, ...) saw this problem coming back in 2002. He proposed an alternative to IDNA called IDNC3 which he claimed wouldn't cause this kind of mess. Looks like nobody listened to him though.

I think that steg provides the opportunity to increase security of already existing crypto. Wouldn't it be plausable to take already encrypted data, and then hide it? Sure, it's not foolproof, but it's no worse than having the encrypted data sent as is.

At the same time however, it seems like steganography has some inherent flaws in it. That is to say, the more people use is, the quicker people will be able to determine patterns in the method. This would allow people/groups/countries/etc. to find the message faster. Doesn't sound like too reasonable of an idea.

Additionally....I'd be interested to see what DJB has to say about steganography...

Yeah, eventually someone will realize that shooting the messenger won't fix the security problems. It's getting to that "eventually" that's hard.

About a month ago, I found a major flaw in UI-Integrate, the system that does EVERYTHING for the University of Illinois (UIC, UIUC, and UIS). Anyway, I found this blatantly obvious (XSS) hole, and wrote up an advisory. Since it was potentially major, I didn't post it publicly. I made slight mention on my blog ("hey, I found a security hole, cool"). I showed up at work the next day (for the UIC computer center) and the shit hit the fan. Someone had cut-n-pasted my blog entry to the Mac mailing list (of all places), which consists of mostly simple mac users, not really in the position to understand computer security. Word got around to the higher-ups and eventually back to my supervisor. I got yelled at... blah blah this is unethical to talk about that, how can you live with yourself, etc, etc. I told them about my usual full-disclosure policy and how I hadn't disclosed any details yet. Eventually they forced me to write some retraction on my blog. They weren't happy with that, so the blog is gone now!!

I was obviously upset at this time, so I e-mailed professor Bernstein (who was my professor last semester in a security holes class), hoping that he would be on my side. He was; he wrote an e-mail to my supervisor about how they should apologize to me, etc.

Anyway, the rest of that week was bureaucratic meetings and ethics lectures. A whole meeting about how full disclosure is bad, how my duty as an employee is to lie to the users of the university computing system, how DJB is a moron* and how I shouldn't listen to him, etc. I thought the whole thing was quite ridiculous and I calmly told all these people that I believed in full disclosure and that I personally agree with DJB. They seemed upset with my "poor ethics", so I told them that if they had a problem with this I wouldn't work here anymore. (They really couldn't fire me because, 1) I would have taken legal action, and 2) I'm one of about three people that are actually worth the $7.30 an hour they pay us.)

*Not the exact words, but the meeting was mostly about discrediting him. This page was referenced. (obviously if you don't like patents you're a loony, right?)

Eventually the incident got escalated to a tech-type (the provost in charge of UofI technology) and he was very helpful. The hole was fixed within hours. I found a hole in their fix, and they fixed that. Over the course of another week they re-engineered the system, and the vendor pushed a patch to the other users.

As soon as it was in the hands of the higher-ups, I was thanked instead of criticized and demeaned. I think I will finally be able to publish the full advisory next week (less than a month after the initial discovery). Overall, I was impressed that people actually cared about security. Both AITS and the vendor involved (Sungard) were very helpful and supportive. It was just the people that didn't understand security that were upset (and scared, it seemed).

So here's my advice to a University student that discovers a hole in their university's computer system: publish immediately. If you publish immediately, the burden will no longer be on you. Everything will be out in the open, and the University will be responsible for their shoddy security, not you. It is your duty to inform the public that the systems they rely on are not secure. It is your right to publish this information. Never let anyone tell you differently. They are wrong. If it comes down to you being dismissed, you will win in court against the Univeristy. Keep that in mind. Always remember that you are doing the right thing.

Don't do what I did and tie yourself up with red tape, it's not worth the emotional drain. I was totally stressed for a week after this. The only thing that sav

Yeah, eventually someone will realize that shooting the messenger won't fix the security problems. It's getting to that "eventually" that's hard.

About a month ago, I found a major flaw in UI-Integrate, the system that does EVERYTHING for the University of Illinois (UIC, UIUC, and UIS). Anyway, I found this blatantly obvious (XSS) hole, and wrote up an advisory. Since it was potentially major, I didn't post it publicly. I made slight mention on my blog ("hey, I found a security hole, cool"). I showed up at work the next day (for the UIC computer center) and the shit hit the fan. Someone had cut-n-pasted my blog entry to the Mac mailing list (of all places), which consists of mostly simple mac users, not really in the position to understand computer security. Word got around to the higher-ups and eventually back to my supervisor. I got yelled at... blah blah this is unethical to talk about that, how can you live with yourself, etc, etc. I told them about my usual full-disclosure policy and how I hadn't disclosed any details yet. Eventually they forced me to write some retraction on my blog. They weren't happy with that, so the blog is gone now!!

I was obviously upset at this time, so I e-mailed professor Bernstein (who was my professor last semester in a security holes class), hoping that he would be on my side. He was; he wrote an e-mail to my supervisor about how they should apologize to me, etc.

Anyway, the rest of that week was bureaucratic meetings and ethics lectures. A whole meeting about how full disclosure is bad, how my duty as an employee is to lie to the users of the university computing system, how DJB is a moron* and how I shouldn't listen to him, etc. I thought the whole thing was quite ridiculous and I calmly told all these people that I believed in full disclosure and that I personally agree with DJB. They seemed upset with my "poor ethics", so I told them that if they had a problem with this I wouldn't work here anymore. (They really couldn't fire me because, 1) I would have taken legal action, and 2) I'm one of about three people that are actually worth the $7.30 an hour they pay us.)

*Not the exact words, but the meeting was mostly about discrediting him. This page was referenced. (obviously if you don't like patents you're a loony, right?)

Eventually the incident got escalated to a tech-type (the provost in charge of UofI technology) and he was very helpful. The hole was fixed within hours. I found a hole in their fix, and they fixed that. Over the course of another week they re-engineered the system, and the vendor pushed a patch to the other users.

As soon as it was in the hands of the higher-ups, I was thanked instead of criticized and demeaned. I think I will finally be able to publish the full advisory next week (less than a month after the initial discovery). Overall, I was impressed that people actually cared about security. Both AITS and the vendor involved (Sungard) were very helpful and supportive. It was just the people that didn't understand security that were upset (and scared, it seemed).

So here's my advice to a University student that discovers a hole in their university's computer system: publish immediately. If you publish immediately, the burden will no longer be on you. Everything will be out in the open, and the University will be responsible for their shoddy security, not you. It is your duty to inform the public that the systems they rely on are not secure. It is your right to publish this information. Never let anyone tell you differently. They are wrong. If it comes down to you being dismissed, you will win in court against the Univeristy. Keep that in mind. Always remember that you are doing the right thing.

Don't do what I did and tie yourself up with red tape, it's not worth the emotional drain. I was totally stressed for a week after this. The only thing that sav

Bernstein warns about this. It seems like it's going to happen anyway.

Anybody know of registrars processing punycode registrations?

Gerrit Pape's runit -- an enhanced, GPL'd workalike of DJB's daemontools might be worth a gander if you haven't noticed it already.

Get ECC type RAM, froma trusted manufacturer, and your set.

Like many other obscure topics, DJBernstein complains about ECC RAM, and has a rant page about it at http://cr.yp.to/hardware/ecc.html

Michael Wally writes "GMail messages are vulnerable to interception..."

You really are a wally if this is news to you. Email is quite fragile and it is by no means private. Use encryption with DJB's Internet Mail 2000.

The goal is nonetheless laudable. Dan Bernstein is quite willing to guarantee his software as being security defect free. I don't see why, although impractical in many cases, it wouldn't be possible to guarantee freedom from explicit defects in a piece of software.

Take a look at his LiveJournal, for example. Well nigh every other post is an ego-wank of a calibre to make even DJB shake his head in shame. Bram's right and everyone else in the world is a moron.

Some years ago, I was on a mailing list with him. During a discussion on building crypto-using apps, a few posters were arguing in favor of making sure apps used parameterizable encryption a/o hashing algorithms -- so when, say, a weakness is discovered in MD5 (hmm ... sounds familiar, no?), you weren't hosed. Bram disagreed, suggesting that merely the app's version number was somehow sufficient for getting around the problem. You just push out an upgrade that uses a new algorithm.

His response to perfectly civil -- oh yeah, and valid, sound, convincing argument that his suggestion was bunk, such as that you can't force users to upgrade, how will new versions play nicely with old, &c, was "Fuck you" and name-calling.

Nice.

I'll still use his protocol, and even donate, because it's about the best we've got right now for what it does, and I appreciate that. But I don't -- and don't have to -- like or respect him.

(Pardon my little rant here.. but this is a general problem and not directed toward this project in particular)

Instead of each program to have its own text configuration files, with a variety of formats, Elektra tries to provide a universal, hierarchical, fast and consistent namespace and infrastructure to access configuration parameters through a key-value pair mechanism.

You mean like.. THE FILESYSTEM?

This always amazes me. The most simple way to store data on a modern machine is to put it in the filesystem. Which is a universal, hierarchical, fast, and consistent namespace and infrastructure to access configuration paramaters (and ANYTHING ELSE) through a key(=path) value(=file) mechanism.

You can also use environment variables for "global" settings.

Most software goes through these stages:

1. ad-hoc monolithic config file (the author is very proud when he's finally debugged it all). Full of settings like "dir = /foo" and "email = me@localhost"
2. introduction of namespaces once he realizes a flat namespace is no good: "global.dir = /foo" and "other.dir = /bar" and "admin.email = me@localhost" and "debug.email = you@localhost"
3. introduction of "include" mechanism once he realizes that monolithic config files are impossible to edit programatically and using "sed" is getting really old. Now the main config file is "include conf.d/*.conf" and the settings have migrated into indivual conf files.
4. realization that not every setting is a simple one-line value. so he moves to XML or some other ungodly thing
5. realization that, hey, wouldn't it be cool if *all* software was like this?

If you are writing a program save yourself a lot of trouble and just cut to the chase. Please don't invent another file format. Please don't write another broken parser. Please don't use XML for anything a human has to edit. Please please don't make me link in an API just to read/write the config settings. Please don't try and prove what big programmer muscles you have.

djb's software is a great example of how powerful and simple this can be.

Active dislike of Sendmail for security reasons, AND a user of QMail?

D. J. Bernstein, is that you? :-)
http://cr.yp.to/

Well I personally go back and forth on this.. I like to share my code but it pisses me off when somebody else screws it up. For instance adding something without a unit test or using different variable name conventions , etc. When I edit other people's code I go out of my way to make my changes look like they "belong".

So, I don't think it's about being beaten up in school (actually, probably more like we were the ones doing the beating :-), just annoyed that something we took a lot of time to do is being pissed on by someone else.

I can totally understand why folks like djb don't allow redistribution of their code with changes. I'm not on his level of course but I'm sure if he BSD'd or GPL'd his code, it would turn to crap in the hands of all the high school Python open-source coders out there.

So I guess what it boils down to is, some programmers are elitist fucks. :-)

Why are we so obsessed with Earth-centered calendaring? Once we've settled half a dozen planets in the next couple of centuries, the UNIX time definition (well, actually TAI to take care of leap seconds properly) is the only one that makes sense independent of local planetary conditions. Yeah, sure, we'll have local calendars too, but the universal standard will be seconds since 1970 or 1955...

Daemontools is over 4 years old...

Just because it (or some other approach) wasn't accepted by some distro does not mean you couldn't have it. They just don't want to break compability....

AC

Looks doubtful. His MCS 590 (High-speed crypto) class already has 9 people signed up, and i have a feeling there will be more.

These advisories were posted to the securesoftware mailing list and therefore conformed to the terminology defined for the list: http://securesoftware.list.cr.yp.to/contributors.h tml.

He does not teach any class regularly -- he is a research professor. This was a special topics class and the class he is scheduled to teach next semester is a very focused 500 level course in high-speed cryptographic algorithms.

Nothing written by James Longstreet is patently misleading in any way. Some previous commenters have managed to read things that weren't there, but hey, this is Slashdot -- it's to be expected.

He does not teach any class regularly -- he is a research professor. This was a special topics class and the class he is scheduled to teach next semester is a very focused 500 level course in high-speed cryptographic algorithms.

Nothing written by James Longstreet is patently misleading in any way. Some previous commenters have managed to read things that weren't there, but hey, this is Slashdot -- it's to be expected.

Why would most students fail? Because DJB is now, and has always been, an asshole.

http://cr.yp.to/2004-494.html

Actual course info from the professor's home page. With assignments, slides, etc.

It looks like the prof let the students know about this during the first class. They knew what was expected and that it would be worth 60% of their grade. This kind of "all the eggs in one basket" assignment should have let all the students that weren't darn sure they could complete it know it was time to get their drop slips in.

It also looks like there was some sort of flexibility for partial credit.

Where's the problem? Oh, I forgot. We're Americans so every time things don't go our way we must be victims. Silly me.

Look on page 3.

happen to look at any of the software here?

http://cr.yp.to/software.html

What a piss poor assignment this was though. Esp considering that the submitter says he went into the "final" with an A and expects to fail.

Hope for a curve on that assignment. Even with tenure, the dept. won't like the fact that 50%+ of the class fails, unless that's the norm. Furthermore, go speak to the prof, esp since you're one who found one of the sec.holes. Explain that one failed assignment shouldn't completely outweigh a semester's worth of A-work. And don't speak only for yourself if able, speak for the class as a whole. Also, remember that there's safety in numbers. Gather as many classmates together and collectively approach him during his office hours.

I recall taking a course and I'd a 98.5% going into the final. The final was 33% of the grade, and I proceeded to completely bomb it (72% or so.) I went and talked to the prof, who knew me from the class of ~150 students. I clearly and calmly explained that I obviously knew the material as demonstrated throughout the semester, and that a single 2-hour exam shouldn't penalize me like it was about to. He agreed, and I got my A in the class as a final grade.

Something to consider! GL to you.

BTW, the best solution to the "database is confusing but mbox is slow and both get corrupted during a crash" problem is Maildir. In the Maildir system each email "folder" is a set of nested directories. New messages go to the "new" subdirectory and are transferred to the "cur" subdirectory the first time they are read by a client. The status of the message (draft, replied, trashed, etc.) is encoded in the filename. Best of all, no file locking is ever required and a crash can't corrupt more than one message.

tcpclient www.slashdot.org 80 cat /dev/urandom

Jeez

Slashdot sucks ;-)

You do realise, I know you do - you're just choosing to ignore it, sowftware is licenced (generally) and not sold. You are sold the right to use it. You aggree to their conditions to use their software.

Your theory is incorrect.

You're being silly. I dare wager that I've expended considerably more effort in administering email systems than you have. But just to be clear : I *want* to solve the problem of Unsolicited Bulk Email. *Solve*, that is, not mitigate. And re-read my post. Would you conclude from it that I don't use such tactics on my own mail servers? Or indeed a range of other measures that sure, work quite effectively today, but likely won't work tomorrow?

Another example : some spamware chokes on multi-line 220 greetings - that's a handy tip that those in the know can take advantage of, but it's not a solution to the problem of Unsolicited Bulk Email. Ditto for secondary MXs that always respond with a 451. Indeed, the irony is that the more widespread such idiosyncracies become known, the less effective the tactics become. That's the nature of the current arms race, and half-baked solutions that don't actually solve the problem just lead us in circles. Hash cash is a half-baked idea. TMDA and challenge response are half-baked ideas. SPF is partially baked at best. SenderID inhabits an alternative reality. DomainKeys shows a glimmer of potential. Internet Mail 2000 is an example of something that I think actually attempts to *solve* the problem, but I won't deny that it's anything other than radical.

So please, for everyone's sake, don't stop showering.

There is no known example of a composite number p that slips past all of these tests; I'm confident that nobody will ever find one by accident.

There is no known example of a composite number p that slips past all of these tests; I'm confident that nobody will ever find one by accident.

As mentioned, DJB's primegen is much faster. Even his Sieve of Eratosthenes implementation will do the primes up to a billion in 1.38 seconds on a 2.4 GHz P4, which is roughly 100x faster than this guy's "all primes below 100 million in less than 13 seconds" (although he doesn't specify on what machine). There's no reason to be using huge memory "pages," you can sieve up to N with any size interval you want (like say, the size of your L1 d-cache) using only Sqrt(N) memory for the primes up to Sqrt(N).

costs up to ten times as much to fix an error by the time it hits the market as it would to catch it during the design.

I don't disagree that it *would be nice* to catch all the bugs before launch but saying that it is cheaper is a false start. Delaying time to market is also extremely expensive in the face of competitors.

I think you're both right.

It is definitely less expensive to ship software without a bug than to ship it with that bug, deal with bug reports from the field, diagnose the bug, fix the bug, risk regressions, and send out patches or new versions.

For highly buggy software, then, the question becomes, what percentage of actual bugs (in shipped software) will actually go through that cycle?

Let's assume 10% of the actual bugs result in user complaints. Right there, that means the extra expense dealing with incoming bug reports would have to be at least 10 times what it would have cost to not ship the bug in the first place for the extra attention to correctness to pay off.

Then, of user complaints, only a certain percentage of bug reports are actually investigated. (Usually, they're prioritized, and the highest-priority ones get investigated first; so, lower-priority bugs might never even be investigated during the product's lifecycle.)

Investigation costs more, but, typically, a lower percentage of overall bugs will be investigated than will be reported.

Repeat this analysis for fixing bugs (which includes providing workarounds, such as "don't use this feature anymore" warnings in documentation) and shipping new software...

...and you end up with the cost-benefit model for Microsoft and its ilk, as well as most FOSS (including Linux, GCC, Emacs) and its ilk.

That is, with most of that software, the actual bug count is assumed to be too high to ever have to worry that all those bugs will come home to roost during the product's lifecycle.

There are exceptions, such as djb's software, including qmail, which (compared to other MTAs) has few features out of the box but has been nearly bug-free (and rock-solid in terms of security) since the 1.03 release many years ago.

But qmail actually highlights the problem: to get almost any feature most Internet sites need for an MTA, third-party patches have to be applied, leading, in many cases, to bugs, even security holes.

IMO the best approach is to decide, for a given product, what sorts of bugs are acceptable and what aren't. For an MTA or anything open to the outside world and especially running as "root", the djb approach of making security a #1 concern seems best, so choose a design that makes it hard for security flaws to exist, especially to propagate among components.

For any software in which a human being composes something online -- this would include text processors, word processors, drawing and painting programs, audio manipulation and music composition programs -- IMO the #1 priority is to NEVER LOSE THE USER'S DATA.

So the language chosen, the coding style, etc. should all be designed to allow the program to crash anytime without losing more than, say, the preceding 1 second of user input, and, ideally, saving (journaling) the user's work in an industry-standard form so the user always has the option of switching over to another product to complete the work.

For a compiler, IMO the #1 priority is to NEVER GENERATE BAD CODE.

Here, the cost of bugs that generate bad code is extremely high. So the design should make it hard for coding errors within the compiler to lead to incorrect code being generated -- better for the compiler to crash and burn than for it to add even more bugs to a program it's generating.

In all these cases, there are eminently practical ways to architect, design, and implement programs accord

The big advantage of kqueue is its speed at handling many simultaneous descriptors.

I agree that BIND is used widely but it has an attrocious security record. Software that has a terrible record of horrible security flaws doesn't just become secure because past bugs are fixed in the current version. Compare the security record of djbdns with BIND for a good example of secure-by-design versus "spaghetti code from decades ago when security didn't matter"

1. The default character encoding resulting from your particular combination of JVM and platform will be correct and non-lossy every time the program is run (e.g. not in Windows, which defaults to ISO8859-1), or;
2. You're certain that the file contains only 7-bit ASCII.

If you want to read characters from a file (or socket) you need to come up with some way to agree on the character encoding and specify it precisely. Not even HTTP does a good job of this--you don't know the character encoding of a request or response until the Content-Type header has been transferred, and often not even then.

What's the character encoding for URLs and domain names? Convention seems to be settling on UTF-8 but AFAIK it's just that.

The equivalent technique that's less risky (but of course much more verbose) is:

BufferedReader r = new BufferedReader(new InputStreamReader(new FileInputStream("foo"), "UTF-8"));
String line;
while ( (line = r.readLine()) != null ) { // etc... }

Where "UTF-8" is a sane default non-lossy character encoding. If you don't know the encoding that was used to write the file you're about to read, you're sort of screwed. You can try some heuristics to try to detect its encoding, or if you're "lucky" you might find a Unicode Byte Order Mark.

Note that none of this headache is particular to Java, it's just that the designers of Java knew early on that a character is not a byte and formalized that distinction (poorly at first) in the language and libraries.

qmail?...I've read through that guy's entire site and I just can't stand his attitude....if you google many people agree. For example his way is the right way. period.

that said if you _MUST_ use qmail make sure to google for one of the many collections of qmail patches (sometimes with install scripts).

One of my problems with qmail is that it's released under a V E R Y vague license, and the author doesn't respond to repeated attempts to clarify what is and is not allowed.
So if he decides to start charging/suing people for commercial use all of a sudden one day don't say I didn't 'told you so'

x86, at this point in time, is a dirty hack. A 16-bit real mode BIOS is a dirty hack. I see no reason why CISC should be used on modern systems. How much code on your system is handcoded assembly? The x86 is designed for handcoded assembly. The PPC and other RISC chips are designed for compiled code.

see http://cr.yp.to

And interstingly, the most recent major security vulnerability (you can take over the computer with one IM) was in code contributed by Novell. Scary!!

link http://cr.yp.to/2004-494/gaim.html

The move to IPv6 will also be another PITA. Daniel Bernstein has an excelent article about this subject with which I completely agree. Due to bad implementation issues, the migranion process isn't easy either.