What does Apple really win by making iTMS clones ubiquitous? Right now, they control the entire experience and dynamics of one of the most popular (non-p2p) music systems available. People buy iPods in order to use iTMS. What do open iTMS clones do but dilute the brand, experience, and goodwill they've already built?
1. A protocol that drastically increases the size and diversity of the routing table without providing a means for existing network providers to mitigate the ensuing explosion has a problem. The fact that Cisco "can" fix a problem in future "revs" doesn't mean that NSPs "can" deploy that fix.
2. If every person on Earth needs to use the Internet to communicate, they can be accomodated in IPv4 addresses using NAT. What is it about translating voices and telephone numbers over the Internet that requires direct addressing? The web works fine with billions of addressable elements and no direct routing support.
3. Regardless of whether routing tables can be made big enough to accomodate IPv6 addresses in the future, they aren't big enough now. What scheme are you referring to that mitigates that problem?
4. Bandwidth can increase independent of the size of an IP address. IPv6 doesn't make the network faster, or in any significant way make TCP any more scalable.
I don't really care too much about this argument (although I'm not an IPv6 believer), but I'd like to see you back your assertions up with logic and evidence.
Like Ultra-Wide-Band networking and enterprise XML integration, this column fits a Cringely mold of writing an entire article about the business plan of one small company most people haven't heard of, and passing it off as an important insight about the IT industry as a whole. It works for the most part because there are a lot of neat-sounding business plans out there. Every start-up company in the world has a story about how their vision, fully realized, would shake up the entire industry. It makes for great column-fodder, but provides poor analyses.
If you read the whole column here twice, you immediately
become aware of the fact that Cringely's entire "argument" turns on the idea that security rests on keeping source code secret. Because "interpeted" code "always" discloses code secrets, "interpreted" platforms like.NET will require the intellectual property wrapped up in schemes like PSCP. Therefore, the "inventors" or PSCP hold an important position on the chess-board of the entire IT industry. Microsoft and Sun will launch bidding wars to ensure they control the PSCP IP.
Of course this is just crazy-talk. Just for a moment, leave aside the argument that something like PSCP can really prevent reverse engineering. In the post-PSCP world, all security rests in a distributed repository of millions of lines of source code "locked up" in an organization that spans 45 buildings and untold tens of thousands of people in Redmond. You can't keep source code secret. Closed source is a speed-bump to dedicated attackers, who will break into networks, find corrupt insiders, or even get janitor temp positions in order to get the code.
Nobody working in security seriously believes that the source code for Windows 2000 wasn't floating around the computer underground years before the most recent disclosure. 'Twas ever thus: most of the SunOS and Solaris exploits that powered attackers in the mid-90's were derived from stolen Sun source code. Stolen source trees have always been the most stable currency in the computer underground for exactly that reason. What you do with the compiled product of that code makes no difference if the blueprints are already in enemy hands.
I'm not sure it's even worth confronting Cringely's argument (that PSCP is a strategic technology that is crucial to.NET security) head-on, but I think I can make a decent response simply by evoking video game copy protection. Companies went through all sorts of contortion to devise copy-protection schemes. Kids with the Microsoft Macro Assembler bible thwarted them, because, just like in the DRM/Media battle, when you control the entire player architecture, it is impossible to completely secure the content. Regardless of whether PSCP makes it harder to grep out the cookie cutter exploit from the.NET IR, the payoff in the "battle" between code-obfuscation and exploit generation is much higher than the payoff to defeat copy protection, and nobody has ever won the copy protection battle.
Cringley is right every once in awhile (business plans occasionally do pan out!), like with Eolas and Burst. I normally
wouldn't care enough to comment, but this time he's inadvertantly promoting a damaging and popular misconception in his article.
the last time I looked the problem still wasn't solved. but the draft is in revision 27 after being taken on by an IETF working group, and still isn't done yet, which should tell you something about how ready it was for prime time when Apple shipped it.
Of course, a huge number of people actually use
Rendezvouz to do useful things on their networks, which
makes your "failure to solve the problem" complaint seem
rather meaningless.
Criticizing Apple for shipping product when the IETF is
in revision twenty-seven of an attempt to simply
explain how Apple's working code is functioning is a
perfect example of why the IETF has slipped further and
further into irrelevance. The fact that namedroppers --- the
IETF DNS discussion group --- is
intensely politicized (a problem that Keith Moore is an
intimate part of) just plays into that.
There's a mythology about the IETF that its core values
are "rough consensus and working code", and that those
values stood in stark contrast to the values of the OSI
standards groups. That may have been true once. But
I ask now: nobody really uses OSI protocols anymore, so
where do we think all those people went? Did they give
up on bitching about standards and go code? Or did they
all go to the IETF?
In any case, calling Apple's work a "big mess" and then comparing it to the shining example of any random
IETF-driven protocol (it's 2004, why don't any of my
ISPs do dynamic DNS? Oh wait, we left it to the IETF to
standardize!) is disingenuous in the extreme.
Apple could tell me that all my DNS records need to be
ASN.1/BER encoded, scrambled with ROT13, encrypted
with 16-bit XOR and compressed with ARJ, and I'd
still install their software before I gave a second thought to
what namedroppers thought about it.
One security screener even asked me to log in, decrypt and look at files on my notebook's desktop
Provide more details. What airport, what circumstances?
Has this ever happened to anybody else, ever? I can't
even remember the last time I had to turn on my laptop,
let alone imagine the screener who knows what "decrypt"
means.
Jerry Ungermann, the president of Check Point, the world's largest vendor of firewalls, boasts that none of his customers was affected by Blaster...
Is this really the president of one of the largest network
security companies in the market claiming that not one
company in Checkpoint's 90% market share was affected
by MSBlaster?
Since the vast majority of SSH connections are just
used to read shell mail and get on IRC, by your logic
we shouldn't care about whether SSH uses DES or
3DES or CAST. We certainly shouldn't care about things
like the CORE CRC compensation attack.
How many CRC-vulnerable SSH sessions have you
broken into?
(crickets)
The point is not that the average Mac user should care
about whether a determined attacker is going to break
their file encryption. The point, which you'd see if you
read the whole thread before commenting, is that
it is valid to deconstruct the Apple marketing message
here and see that it is based off a bogus assumption.
Regardless of the fact that I, like many Mac users (who
include a surprising number of other computer security
researchers), do care about how secure the
native crypto capabilities are, the notion that you can
quantify security by things like key length is a fallacy that
knowledgeable people should combat.
The only way passphrases can be secure is if they are not
easily typeable. Adding the "easily remembered, easily
typed" constraint on a key is a huge constraint!
This is a fundamental trade-off, and again, I think it
makes the type of encryption used in the system a mostly
moot point.
Brute forcing the whole key expansion function (ie, the
whole key space) is very hard. Obviously. That's the
purpose of having a large key space.
Brute forcing an actual crypto implementation, when the
keyspace is limited by semantics and user constraints,
is NOT very hard. The original point is valid: if most users
are going to use easily-typed English words, that's the
weak point of the system people are going to attack.
In that sense, for the overwhelming majority of Mac users,
it wouldn't matter if the cryptosystem used DES, or even
pkzip-encryption; a determined attacker is going to break
the system with the password.
For many years, Bernstein has had
web notes for a crypto course
online, but inaccessible, "pending the outcome
of his case". I wonder if those will be published
now.
... on the other hand, Dan Bernstein's qmail MTA is
some of the gnarliest code I've ever read (large portions
of it are generated from CPP macros!). Despite
qmail's status as one of the top 4 MTAs on the Internet,
and huge incentives to find security flaws, Bernstein
hasn't had to cut a new release since 1998,
and there has never been a security flaw
found in the qmail code.
Bernstein would probably tell you that the problem is not
the C language, but in lack of secure program designs
(which are language-independent) and error-prone,
outmoded standard libraries.
"A large number of providers offer IPv6 support today", says Jared Mauch. Including NTT/Verio, and, uh, who else?
Worldcom, Sprint, Qwest, AT&T, SBC. Which of these offer
IPv6? Which are cooperating with other providers to transit
IPv6 traffic?
Maybe they all are (I hadn't heard!), but be specific. It doesn't count until the tier-1 service providers are supporting it and syncing up with each other. Until
then, it's a toy.
Multicasting is not a good excuse to switch to v6.
There are evident, unsolved, pragmatic problems with
native IP multicast. For instance, there is no proven,
support inter-domain multicast routing system, and
thus no way for multicast groups to sync up between
different ISPs.
There are application-layer problems with multicast.
For instance, nobody has come up with a reliability
scheme with a service model other than "streaming
video" or "big fucking file transfer" (as opposed to,
say, web page download).
But even if you believe that problems like these are
close to being solved, there is a fundamental, intensely
painful scaleability problem with global native IP
multicast: rather than asking the Internet backbone
to route entities that represent hosts (a hard enough
problem), native multicast demands that the backbone
route entities that effectively represent pieces of
content. As in, web pages.
Most of the benefits of multicast will come from overlay
systems, both centralized (like the one Akamai built) and
decentralized (like peer-to-peer file sharing networks).
There's no evidence that the problems Deering-model
multicast aims to solve can't be solved more easily at
a higher layer.
By default OpenBSD only sets Sendmail to listen on localhost. So their slogan ("only one remote root hole in 7 years") doesn't have to change --- not that it was a particularly strong claim to begin with.
However, OpenBSD claims an "audited Sendmail", which is what many OpenBSD operators will enable if they want mail --- all those people get rooted, because they trusted OpenBSD's auditing claims over the architecture improvements offered by qmail and Postfix.
Anybody can craft a security claim that is hard to knock down. "7 years without a security hole in a locked down web server configuration with no remote access!". "7 years without a security hole exploitable when deployed behind a firewall that allows no TCP connections!".
The only interesting claim is "7 years without a remote security hole". No qualifiers. When OpenBSD got rooted with their own "audited" SSH port, they should have dropped the bug counting claim. As it stands, OpenBSD's security posture has not served OpenBSD operators this month.
I agree that Sendmail's monolithic architecture, which makes it easier to run as root than as an unprivileged user, is a problem. The fact that most operators leave it in an out-of-the-box configuration running as root exacerbates this problem.
However, I don't think the "Sendmail problem" boils down simply to "it runs as root".
First off, the notion that operators can render threats irrelevant by running services unprivileged and chrooted is a fallacy. Consider the Slammer worm (by far the most expensive security problem published this year) --- a vulnerable population of 70,000 boxes, each of which only needed access to sockets to propagate, covered the entire Internet in less than 11 minutes. Bugs that give you remote shell are a problem. When those bugs appear in monoculture implementations (and SMTP is a recovering monoculture, where Sendmail had a monopoly for a decade), worm susceptibility is a huge problem regardless of how privileges are divided.
Secondly, and more apropos this discussion, think about what you get out of a Sendmail exploit even if it isn't running as root. Since Sendmail doesn't divide privileges with fine-grained roles (like qmail and Postfix), you've still got the target's mail completely under your control. This is still a nightmare scenario from a security perspective.
The real problem here is Sendmail, not Sendmail configurations. It's 2003, and I'm just not sure there's any excuse for running rusty old Sendmail anymore.
Exim is not a credible secure alternative to Sendmail. It shares the same architecture that makes Sendmail a poster child for susceptability.
The two credible alternatives are Postfix and qmail. Both Postfix and qmail seperate the mail system into a number of fine-grained roles, each with a seperate UID and control over a specific set of resources. Regardless of what vulnerabilities are harbored by the Postfix or qmail code, a bug in either is very unlikely to leave an attacker with root access, or even control over the mail system.
In addition to a coherent architecture that addresses security, both Postfix and qmail were implemented from the ground up to resist textbook attacks like file races, buffer overflows, and metacharacter problems. When I
briefly audited Exim in 1997, it was immediately clear to me that Exim could not make the same claim.
You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".
You don't know what you're talking about.
Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed
vulnerability reports. You're simply not allowed
to distribute adulterated source code or your
own "fixed" binaries.
This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of
the most widely used MTAs on the Internet. The
incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.
You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".
You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.
The article lacks credibility.
Security is a complex issue. There are very few
organizations qualified to present it authoritatively. Who is NewsFactor? Who is Masha Zager? What is the "Informations Systems Security Association"?
Ignores the worm gene pool.
Several of the Linux worms cited use the same (uncommon) vulnerabilities to gain access to
computers. Putting a different payload on the
same attack doesn't make the "different worms"
uniquely different threats.
Newer != Insecure.
SunOS is old, and insecure. djbdns is brand new, and very secure. Secure programming, and (more importantly) secure design, are new disciplines.
Linux != New.
Linux is new in implementation, but evidences
the classic Unix security model. The Unix model
is flawed, but not impossible. Win32 has a
"better" design, but does nothing to make that
apparent (in the same sense as Darwin doesn't make
apparent its microkernel design).
Bug Counting?
Most Linux bugs are in packages. There are
thousands of available packages, virtually all
with published source code. Third-party QA teams
at ISS and Network Associates can go make a list
of 100 CGI programs, read bad source code for a
week, and generate 15-20 new advisories. Very,
very few of them will affect real, deployed
systems.
Still More Bug Counting!
Linux sees more bug reports. Linux has published
source code. An independant QA person can spend
a month looking for a remote attack on Win32,
come up with one, and coast on it for a year ---
that remote hole will probably affect 80% of
all deployed systems. To get the same cred,
you need to find tens of holes in popular
Linux packages. It is both significantly easier and more useful (to the reporter) to find
numerous Linux-related holes.
Why is Carbon better for porting C/C++ applications from other platforms over? C/C++ works just as well
under Cocoa alongside Objective C as it does in Carbon. Moreover, coming from another platform, you're still going to wind up porting your UI code to a new toolkit. What makes you think the low level toolkit is easier to port to than the high level one?
Mach isn't a NeXT idea; it's a
CMU idea. NeXT and Darwin aren't the only Mach operating systems.
You could develop for Mozilla (and, with some
effort, wind up with something that would work
in the COM/ATL/XYZ equivalent environment that
Windows provides). You might even be productive
in that environment. But you're not developing
and OS X application, and you shouldn't kid
yourself.
Mozilla/XUL on OS X is hard to take. It reimplements the entire UI toolkit (and what it comes up with
looks nothing like the Apple guidelines). It's
also incredibly slow (as in, KEYSTROKE LAG in
text inputs!). And unlike in Win32, where IE
can hide in the background and leave you with
something that looks like an application, in
OS X you'll be literally running your application
through the nightmarishly bloated Mozilla environment.
You're also kidding yourself if you think you'll
wind up with something cross-platform. XPCOM
doesn't magically make a C library compiled PPC
Mach-O work on x86 ELF.
Don't get me wrong; I like the COM/DOM/C++
environment and have worked on teams that used
it successfully. But right now I think it's
mostly applicable to dynamic web applications
(people put up with more in client/server
situations).
If you follow a sane strategy, and don't use Objective C OR Carbon C++ (and its associated
event and I/O management cruft) to handle your
application logic, I don't see what the advantage
to Carbon is.
That is to say, if all your application logic is
straight C++, and you're only doing UI and event
integration in "Native" MacOS, why would you
choose to use Carbon (which seems approximately
as complex as Win32) instead of Cocoa?
If you need "clean and easy" integration with "BSD IPC" (the native programming interface of the underlying Darwin operating system), you need to be able to use its C-language calling interface. Of the 3 kits you mentioned, Cocoa/Objective-C is the only one that offers that.
The ready-made integration offered by your two Java alternatives may not be useful for hardcore I/O anyways. How do you get a handle on an fd-based resource (/dev/bpf*, for instance) and then integrate the fd with your event loop?
My moving-forward plan has been to maintain my application logic in standard C/C++, and use Cocoa/ObjC to build UI (and nothing else) on top of that. Since most good BSD code is asynchronous, and Cocoa/CoreFoundation lets you control the event loop at the "select()" level, this works fine for me.
Slashdot Mirror
What does Apple really win by making iTMS clones ubiquitous? Right now, they control the entire experience and dynamics of one of the most popular (non-p2p) music systems available. People buy iPods in order to use iTMS. What do open iTMS clones do but dilute the brand, experience, and goodwill they've already built?
1. A protocol that drastically increases the size and diversity of the routing table without providing a means for existing network providers to mitigate the ensuing explosion has a problem. The fact that Cisco "can" fix a problem in future "revs" doesn't mean that NSPs "can" deploy that fix.
2. If every person on Earth needs to use the Internet to communicate, they can be accomodated in IPv4 addresses using NAT. What is it about translating voices and telephone numbers over the Internet that requires direct addressing? The web works fine with billions of addressable elements and no direct routing support.
3. Regardless of whether routing tables can be made big enough to accomodate IPv6 addresses in the future, they aren't big enough now. What scheme are you referring to that mitigates that problem?
4. Bandwidth can increase independent of the size of an IP address. IPv6 doesn't make the network faster, or in any significant way make TCP any more scalable.
I don't really care too much about this argument (although I'm not an IPv6 believer), but I'd like to see you back your assertions up with logic and evidence.
Like Ultra-Wide-Band networking and enterprise XML integration, this column fits a Cringely mold of writing an entire article about the business plan of one small company most people haven't heard of, and passing it off as an important insight about the IT industry as a whole. It works for the most part because there are a lot of neat-sounding business plans out there. Every start-up company in the world has a story about how their vision, fully realized, would shake up the entire industry. It makes for great column-fodder, but provides poor analyses.
If you read the whole column here twice, you immediately become aware of the fact that Cringely's entire "argument" turns on the idea that security rests on keeping source code secret. Because "interpeted" code "always" discloses code secrets, "interpreted" platforms like .NET will require the intellectual property wrapped up in schemes like PSCP. Therefore, the "inventors" or PSCP hold an important position on the chess-board of the entire IT industry. Microsoft and Sun will launch bidding wars to ensure they control the PSCP IP.
Of course this is just crazy-talk. Just for a moment, leave aside the argument that something like PSCP can really prevent reverse engineering. In the post-PSCP world, all security rests in a distributed repository of millions of lines of source code "locked up" in an organization that spans 45 buildings and untold tens of thousands of people in Redmond. You can't keep source code secret. Closed source is a speed-bump to dedicated attackers, who will break into networks, find corrupt insiders, or even get janitor temp positions in order to get the code.
Nobody working in security seriously believes that the source code for Windows 2000 wasn't floating around the computer underground years before the most recent disclosure. 'Twas ever thus: most of the SunOS and Solaris exploits that powered attackers in the mid-90's were derived from stolen Sun source code. Stolen source trees have always been the most stable currency in the computer underground for exactly that reason. What you do with the compiled product of that code makes no difference if the blueprints are already in enemy hands.
I'm not sure it's even worth confronting Cringely's argument (that PSCP is a strategic technology that is crucial to .NET security) head-on, but I think I can make a decent response simply by evoking video game copy protection. Companies went through all sorts of contortion to devise copy-protection schemes. Kids with the Microsoft Macro Assembler bible thwarted them, because, just like in the DRM/Media battle, when you control the entire player architecture, it is impossible to completely secure the content. Regardless of whether PSCP makes it harder to grep out the cookie cutter exploit from the .NET IR, the payoff in the "battle" between code-obfuscation and exploit generation is much higher than the payoff to defeat copy protection, and nobody has ever won the copy protection battle.
Cringley is right every once in awhile (business plans occasionally do pan out!), like with Eolas and Burst. I normally wouldn't care enough to comment, but this time he's inadvertantly promoting a damaging and popular misconception in his article.
Of course, a huge number of people actually use Rendezvouz to do useful things on their networks, which makes your "failure to solve the problem" complaint seem rather meaningless.
Criticizing Apple for shipping product when the IETF is in revision twenty-seven of an attempt to simply explain how Apple's working code is functioning is a perfect example of why the IETF has slipped further and further into irrelevance. The fact that namedroppers --- the IETF DNS discussion group --- is intensely politicized (a problem that Keith Moore is an intimate part of) just plays into that.
There's a mythology about the IETF that its core values are "rough consensus and working code", and that those values stood in stark contrast to the values of the OSI standards groups. That may have been true once. But I ask now: nobody really uses OSI protocols anymore, so where do we think all those people went? Did they give up on bitching about standards and go code? Or did they all go to the IETF?
In any case, calling Apple's work a "big mess" and then comparing it to the shining example of any random IETF-driven protocol (it's 2004, why don't any of my ISPs do dynamic DNS? Oh wait, we left it to the IETF to standardize!) is disingenuous in the extreme. Apple could tell me that all my DNS records need to be ASN.1/BER encoded, scrambled with ROT13, encrypted with 16-bit XOR and compressed with ARJ, and I'd still install their software before I gave a second thought to what namedroppers thought about it.
Provide more details. What airport, what circumstances? Has this ever happened to anybody else, ever? I can't even remember the last time I had to turn on my laptop, let alone imagine the screener who knows what "decrypt" means.
Is this really the president of one of the largest network security companies in the market claiming that not one company in Checkpoint's 90% market share was affected by MSBlaster?
How many CRC-vulnerable SSH sessions have you broken into?
(crickets)
The point is not that the average Mac user should care about whether a determined attacker is going to break their file encryption. The point, which you'd see if you read the whole thread before commenting, is that it is valid to deconstruct the Apple marketing message here and see that it is based off a bogus assumption.
Regardless of the fact that I, like many Mac users (who include a surprising number of other computer security researchers), do care about how secure the native crypto capabilities are, the notion that you can quantify security by things like key length is a fallacy that knowledgeable people should combat.
This is a fundamental trade-off, and again, I think it makes the type of encryption used in the system a mostly moot point.
Brute forcing an actual crypto implementation, when the keyspace is limited by semantics and user constraints, is NOT very hard. The original point is valid: if most users are going to use easily-typed English words, that's the weak point of the system people are going to attack.
In that sense, for the overwhelming majority of Mac users, it wouldn't matter if the cryptosystem used DES, or even pkzip-encryption; a determined attacker is going to break the system with the password.
No, because GPGME is GPL, not LGPL, and all it does is make calls to the (GPL) GPG binary.
Bernstein would probably tell you that the problem is not the C language, but in lack of secure program designs (which are language-independent) and error-prone, outmoded standard libraries.
Worldcom, Sprint, Qwest, AT&T, SBC. Which of these offer IPv6? Which are cooperating with other providers to transit IPv6 traffic?
Maybe they all are (I hadn't heard!), but be specific. It doesn't count until the tier-1 service providers are supporting it and syncing up with each other. Until then, it's a toy.
There are evident, unsolved, pragmatic problems with native IP multicast. For instance, there is no proven, support inter-domain multicast routing system, and thus no way for multicast groups to sync up between different ISPs.
There are application-layer problems with multicast. For instance, nobody has come up with a reliability scheme with a service model other than "streaming video" or "big fucking file transfer" (as opposed to, say, web page download).
But even if you believe that problems like these are close to being solved, there is a fundamental, intensely painful scaleability problem with global native IP multicast: rather than asking the Internet backbone to route entities that represent hosts (a hard enough problem), native multicast demands that the backbone route entities that effectively represent pieces of content. As in, web pages.
Most of the benefits of multicast will come from overlay systems, both centralized (like the one Akamai built) and decentralized (like peer-to-peer file sharing networks). There's no evidence that the problems Deering-model multicast aims to solve can't be solved more easily at a higher layer.
It's just another example of the end to end principle in action.
If it was a zero-cost, zero-risk operation, it would be enabled. Like IP multicast, it's not zero-cost, and isn't enabled.
However, OpenBSD claims an "audited Sendmail", which is what many OpenBSD operators will enable if they want mail --- all those people get rooted, because they trusted OpenBSD's auditing claims over the architecture improvements offered by qmail and Postfix.
Anybody can craft a security claim that is hard to knock down. "7 years without a security hole in a locked down web server configuration with no remote access!". "7 years without a security hole exploitable when deployed behind a firewall that allows no TCP connections!".
The only interesting claim is "7 years without a remote security hole". No qualifiers. When OpenBSD got rooted with their own "audited" SSH port, they should have dropped the bug counting claim. As it stands, OpenBSD's security posture has not served OpenBSD operators this month.
However, I don't think the "Sendmail problem" boils down simply to "it runs as root".
First off, the notion that operators can render threats irrelevant by running services unprivileged and chrooted is a fallacy. Consider the Slammer worm (by far the most expensive security problem published this year) --- a vulnerable population of 70,000 boxes, each of which only needed access to sockets to propagate, covered the entire Internet in less than 11 minutes. Bugs that give you remote shell are a problem. When those bugs appear in monoculture implementations (and SMTP is a recovering monoculture, where Sendmail had a monopoly for a decade), worm susceptibility is a huge problem regardless of how privileges are divided.
Secondly, and more apropos this discussion, think about what you get out of a Sendmail exploit even if it isn't running as root. Since Sendmail doesn't divide privileges with fine-grained roles (like qmail and Postfix), you've still got the target's mail completely under your control. This is still a nightmare scenario from a security perspective.
The real problem here is Sendmail, not Sendmail configurations. It's 2003, and I'm just not sure there's any excuse for running rusty old Sendmail anymore.
The two credible alternatives are Postfix and qmail. Both Postfix and qmail seperate the mail system into a number of fine-grained roles, each with a seperate UID and control over a specific set of resources. Regardless of what vulnerabilities are harbored by the Postfix or qmail code, a bug in either is very unlikely to leave an attacker with root access, or even control over the mail system.
In addition to a coherent architecture that addresses security, both Postfix and qmail were implemented from the ground up to resist textbook attacks like file races, buffer overflows, and metacharacter problems. When I briefly audited Exim in 1997, it was immediately clear to me that Exim could not make the same claim.
You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".
You don't know what you're talking about. Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed vulnerability reports. You're simply not allowed to distribute adulterated source code or your own "fixed" binaries.
This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of the most widely used MTAs on the Internet. The incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.
You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".
You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.
What the hell are you talking about?
Mach isn't a NeXT idea; it's a CMU idea. NeXT and Darwin aren't the only Mach operating systems.
Mozilla/XUL on OS X is hard to take. It reimplements the entire UI toolkit (and what it comes up with looks nothing like the Apple guidelines). It's also incredibly slow (as in, KEYSTROKE LAG in text inputs!). And unlike in Win32, where IE can hide in the background and leave you with something that looks like an application, in OS X you'll be literally running your application through the nightmarishly bloated Mozilla environment.
You're also kidding yourself if you think you'll wind up with something cross-platform. XPCOM doesn't magically make a C library compiled PPC Mach-O work on x86 ELF.
Don't get me wrong; I like the COM/DOM/C++ environment and have worked on teams that used it successfully. But right now I think it's mostly applicable to dynamic web applications (people put up with more in client/server situations).
If you follow a sane strategy, and don't use Objective C OR Carbon C++ (and its associated event and I/O management cruft) to handle your application logic, I don't see what the advantage to Carbon is.
That is to say, if all your application logic is straight C++, and you're only doing UI and event integration in "Native" MacOS, why would you choose to use Carbon (which seems approximately as complex as Win32) instead of Cocoa?
The ready-made integration offered by your two Java alternatives may not be useful for hardcore I/O anyways. How do you get a handle on an fd-based resource (/dev/bpf*, for instance) and then integrate the fd with your event loop?
My moving-forward plan has been to maintain my application logic in standard C/C++, and use Cocoa/ObjC to build UI (and nothing else) on top of that. Since most good BSD code is asynchronous, and Cocoa/CoreFoundation lets you control the event loop at the "select()" level, this works fine for me.