First we need a patch, and one that still loads our zone files, please.
Some BIND 8 security updates tightend some security-unrelated consistency checks, too, making upgrades suprisingly hard. After such experiences, nobody rushes to make updates, unless absolutely forced to.
ISS did not inform any of the Unix vendors. They are pretty pissed about it.
So what? Vendors don't care. Sun even released a new version of Solaris with BIND and the TSIG bug, even though their previous version wasn't vulnerable (no DNSSEC support). It's been known for long that the BIND 8 DNSSEC is especially flakey, and if someone distributes compiled BIND 8 binaries with enabled DNSSEC, he's willing to take the risk and partly to blame for it. At the moment, nobody really needs DNSSEC, certainly not the (relative) masses who install precompiled BIND binaries.
In addition, I strongly doubt that it is the duty of the researcher to contact distributors.
Speaking of duties, ISC really should publish the patches now.
Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?
In this case, ISS did not rush ahead. This was a coordinated release. Of course, something went horribly wrong, but I don't think ISS is to blame for it (maybe they could have warned ISC that their approach wouldn't work out, though).
Alternatively, you could update to the latest version of BIND.
Among other things, BIND 9 implements stricter checking on zones than BIND 8, so it's a not a drop-in replacement which you can install during a random afternoon, completely unscheduled.
It appears as if ISC has learnt from a certain BSD vendor how to push technology. They really want to encourage people to move over to BIND 3.4^W9, but I really wish they were are bit more responsible.
gcc is built for portability, not speed. VC++'s code is faster
This is no longer true, vanilla Microsoft Visual C++ is not faster than GCC anymore. There are compilers which can do much better than GCC on certain platforms, but Visual C++ isn't one of the, usually.
In addition, unless you've got some real-time applications which scratches at the limits of the currently available hardware, machine code quality doesn't matter a lot. If you use a compiler, you've already made a compromise in terms of effort vs. speed, and maybe you can shift the balance even further and concentrate on features which directly benefit your customers instead of dealing with cross-vendor compatibility issues.
The survery claims to asked questions relating to state monopolies. But did they ask about monopolies in general?
I don't think so. In Germany, the intertwined nature of the mainstream press is not transparent. Most of the ties are publicly documented, but they are usually only used (if they are used at all) to quietly control who happens to own a press. Such information is not available in most countries which were surveyed, so it wouldn't be fair to take it into account in the study for countries with a more transparent press.
In what other countries that are supposedly better than us are the press free to walk out into public with a Swastika armband, yell "HEIL HITLER" at the top of your lungs, and give the Roman salute?
A few Scandinavian countries, I think.
Going to a more serious matter, which of those European countries would allow a true report on the pernicious effects of uncontrolled illegal immigration?
All Western European countries. Freedom of the press is for those who happen to own one. Self-inflicted (or market-inflicted) censorship was not taken into account by this study. (Whatever information a "true report on the pernicious effects of uncontrolled illegal immigration" would contain.)
Most of their presses are so controlled by political correctness that you cannot offend anyone or anything.
Oh, the press happily publishes Hitler comparisons, even if they are politically incorrect.
Close off ports 137 and 138 on any WAN connections.
Have you actually tested this? The messenger service can also be reached via the portmapper-like service on port 135/UDP and some service-specific dynamic UDP port.
Journaling your filesystem allows you to maintain integrity through a system crash or power outage.
It depends on the type of system crash. If the file system code itself crashes, it's not too unlikely that journalling won't help.
Furthermore, writing a sector is not atomic, and there are a few drives which can kill journalling (e.g. when a partially written sector becomes unreadable).
It appears as if PGP Corporation has changed the PGP business model: perpetual licenses are now available. I see this with mixed feelings: it's good for PGP and use of encryption in general, but one major incentive to invest into GnuPG instead of PGP is gone...
(And BTW, they've managed to fix their web shop; it seems to be working now.)
Microsoft never cared about quality because they had a monopoly.
A few years ago, Microsoft didn't have a monopoly at all. But the competition couldn't really compete on quality (or security, for that matter). The UNIX camp had it's internal conflicts, IBM marketed OS/2 as a Windows emulator (and got cautious when it was too successful in Germany), and MacOS required a brainwash to view its qualitiy (and most of it's security was the result of a single-user system).
The market demanded only a very basic level of software quality, and Microsoft delivered software which matched the expectations of the market. What else could have made Microsoft such a huge company? Alien influence?
Apart from that, I believe that charging for critical security information is morally wrong (and not in the "proprietary software is bad" sense, but in the "not warning your neighbor when he's about to get hurt" sense). But who's seriously into (the very practical aspects of) computer security and does not sell e.g. early-access information?
Otherwise, what's the next license change going to look like?
I agree that the hidden relicense clause is quite obnoxious, and it's something I can't deal with. I need version control badly, and I can't suddenly switch systems just because the vendor decided to change the license in some obscure way, making it unacceptable to me.
However, it's funny that you bring up Perforce in this context. Perforce grants gratis licenses for free software development for just one year. After this time period, the licensed apparently has to be renewed.
Buy Bitmover and release Bitkeeper under the GPL? You want to reward him for this sort of behavior? I'd rather direct my goodwill wishing at someone or some company a bit nobler.....
What behavior? Actually, I'm not sure if Larry McVoy is the evil guy here. He couldn't do any harm to the free software community if people playing key roles in the community weren't using his software (thus forcing others to do so as well).
Aegis implements a process, not just version control, and many people are cautious about software which forces them to work in a certain way (until they have been using it for years, then it becomes The One True Way). Most Aegis newcomers who are forced to use it by the project maintainer will detest it because it encourages (forces?) them to write test cases along their changes...
However, the process implemented by Aegis closely mirrors the Linux development process: a developer makes changes, some subsystem maintainer reviews it, and Linus integrates it into the official tree. But there's a drawback: this only works if all developers have access to the same repository, on the same filesystem.:-(
Aegis has got a distributed development model, but it doesn't offer the same repository tracking features as Bitkeeper. I don't know if this is relevant in the kernel context, IIRC Linus has complained more than once that the repository tracking (which links changesets to particular repositories/revisions) prevents him from automatically applying patches to the master repository.
It's a New EULA, so the old one did not mention it? The solution is simple: continue to use your existing version.
The old EULA is revoked automatically as soon as Bitmover changes the Bitkeeper test suite so that the old version no longer passes it. In essence, this means that Bitmover can revoke old licenses at any time.
IANAL, but I know I can't rely on Bitkeeper (the vendor doesn't want me to, obviously). Maybe the commercially sold version is different, I don't know.
Bitkeeper is probably really nice software, so we can only hope that Red Hat (or someone else) buys Bitmover one day and licenses Bitkeeper under the GPL.
Currently, we don't know if the PPTP bug is real or a fake. Anyone can write an advisory like this, and there is no way you can tell if they tell the truth or not, unless you look carefully at the source code.
Okay, maybe you can confirm that their claim is true using some black box testing. Unfortunately, the guys with the unlimited time budget aren't the good ones, usually.
I don't understand the purpose of this advisory, really (at least not from a technical perspective). I don't think anyone has got a policy to disable any services based on such information. Microsoft won't admit that there is a problem until they have got a some fix. The bad guys will work overtime to discover the exact nature of this security defect, and the good guys will work overtime as usual, but are busy with other issues.
Slashdot Mirror
So patch SOON.
First we need a patch, and one that still loads our zone files, please.
Some BIND 8 security updates tightend some security-unrelated consistency checks, too, making upgrades suprisingly hard. After such experiences, nobody rushes to make updates, unless absolutely forced to.
ISS did not inform any of the Unix vendors. They are pretty pissed about it.
So what? Vendors don't care. Sun even released a new version of Solaris with BIND and the TSIG bug, even though their previous version wasn't vulnerable (no DNSSEC support). It's been known for long that the BIND 8 DNSSEC is especially flakey, and if someone distributes compiled BIND 8 binaries with enabled DNSSEC, he's willing to take the risk and partly to blame for it. At the moment, nobody really needs DNSSEC, certainly not the (relative) masses who install precompiled BIND binaries.
In addition, I strongly doubt that it is the duty of the researcher to contact distributors.
Speaking of duties, ISC really should publish the patches now.
Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?
In this case, ISS did not rush ahead. This was a coordinated release. Of course, something went horribly wrong, but I don't think ISS is to blame for it (maybe they could have warned ISC that their approach wouldn't work out, though).
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
BIND 8 supports DNSSEC, too. Unfortunately, I have to say--so far, this part of BIND 8 contained the nastiest security bugs.
Alternatively, you could update to the latest version of BIND.
Among other things, BIND 9 implements stricter checking on zones than BIND 8, so it's a not a drop-in replacement which you can install during a random afternoon, completely unscheduled.
It appears as if ISC has learnt from a certain BSD vendor how to push technology. They really want to encourage people to move over to BIND 3.4^W9, but I really wish they were are bit more responsible.
gcc is built for portability, not speed. VC++'s code is faster
This is no longer true, vanilla Microsoft Visual C++ is not faster than GCC anymore. There are compilers which can do much better than GCC on certain platforms, but Visual C++ isn't one of the, usually.
In addition, unless you've got some real-time applications which scratches at the limits of the currently available hardware, machine code quality doesn't matter a lot. If you use a compiler, you've already made a compromise in terms of effort vs. speed, and maybe you can shift the balance even further and concentrate on features which directly benefit your customers instead of dealing with cross-vendor compatibility issues.
The survery claims to asked questions relating to state monopolies. But did they ask about monopolies in general?
I don't think so. In Germany, the intertwined nature of the mainstream press is not transparent. Most of the ties are publicly documented, but they are usually only used (if they are used at all) to quietly control who happens to own a press. Such information is not available in most countries which were surveyed, so it wouldn't be fair to take it into account in the study for countries with a more transparent press.
In what other countries that are supposedly better than us are the press free to walk out into public with a Swastika armband, yell "HEIL HITLER" at the top of your lungs, and give the Roman salute?
A few Scandinavian countries, I think.
Going to a more serious matter, which of those European countries would allow a true report on the pernicious effects of uncontrolled illegal immigration?
All Western European countries. Freedom of the press is for those who happen to own one. Self-inflicted (or market-inflicted) censorship was not taken into account by this study. (Whatever information a "true report on the pernicious effects of uncontrolled illegal immigration" would contain.)
Most of their presses are so controlled by political correctness that you cannot offend anyone or anything.
Oh, the press happily publishes Hitler comparisons, even if they are politically incorrect.
signed by internet [...] pioneers
Who are they? Is it reasonable to call someone an "Internet pioneer" even if he or she hasn't (co-)authored an RFC carrying a three-digit number?
Any member of the public, including private persons, corporate entities, and government agencies, may file a protest under 37 CFR 1.291.
Nice idea, but 1.291 reads:
1.291 Protests by the public against pending applications.
It's too late for this kind of action.
Isn't an UART at least partly an asynchronous chip? So you probably have got one your PC today...
And Chuck Moore's description of an asynchronous Forth chip is available in Google's cache (I don't know why he pulled it from the web site).
I think this idea has been borrowed from GNU's libiberty, the GNU portability library which frees you from the restrictions of a particular platform.
Close off ports 137 and 138 on any WAN connections.
Have you actually tested this? The messenger service can also be reached via the portmapper-like service on port 135/UDP and some service-specific dynamic UDP port.
Probably by an extension of the UN War Crimes court into a body to deal with inter-country legal affairs that aren't War Crimes.
There's the International Criminal Court, but the United States are actively undermining it.
Journaling your filesystem allows you to maintain integrity through a system crash or power outage.
It depends on the type of system crash. If the file system code itself crashes, it's not too unlikely that journalling won't help.
Furthermore, writing a sector is not atomic, and there are a few drives which can kill journalling (e.g. when a partially written sector becomes unreadable).
It appears as if PGP Corporation has changed the PGP business model: perpetual licenses are now available. I see this with mixed feelings: it's good for PGP and use of encryption in general, but one major incentive to invest into GnuPG instead of PGP is gone...
(And BTW, they've managed to fix their web shop; it seems to be working now.)
Microsoft never cared about quality because they had a monopoly.
A few years ago, Microsoft didn't have a monopoly at all. But the competition couldn't really compete on quality (or security, for that matter). The UNIX camp had it's internal conflicts, IBM marketed OS/2 as a Windows emulator (and got cautious when it was too successful in Germany), and MacOS required a brainwash to view its qualitiy (and most of it's security was the result of a single-user system).
The market demanded only a very basic level of software quality, and Microsoft delivered software which matched the expectations of the market. What else could have made Microsoft such a huge company? Alien influence?
Apart from that, I believe that charging for critical security information is morally wrong (and not in the "proprietary software is bad" sense, but in the "not warning your neighbor when he's about to get hurt" sense). But who's seriously into (the very practical aspects of) computer security and does not sell e.g. early-access information?
I think it's most likely that the author didn't know better.
Declan McCullagh wrote both articles. I'm sure he knew what he was doing.
Otherwise, what's the next license change going to look like?
I agree that the hidden relicense clause is quite obnoxious, and it's something I can't deal with. I need version control badly, and I can't suddenly switch systems just because the vendor decided to change the license in some obscure way, making it unacceptable to me.
However, it's funny that you bring up Perforce in this context. Perforce grants gratis licenses for free software development for just one year. After this time period, the licensed apparently has to be renewed.
Buy Bitmover and release Bitkeeper under the GPL? You want to reward him for this sort of behavior? I'd rather direct my goodwill wishing at someone or some company a bit nobler.....
What behavior? Actually, I'm not sure if Larry McVoy is the evil guy here. He couldn't do any harm to the free software community if people playing key roles in the community weren't using his software (thus forcing others to do so as well).
Aegis implements a process, not just version control, and many people are cautious about software which forces them to work in a certain way (until they have been using it for years, then it becomes The One True Way). Most Aegis newcomers who are forced to use it by the project maintainer will detest it because it encourages (forces?) them to write test cases along their changes...
:-(
However, the process implemented by Aegis closely mirrors the Linux development process: a developer makes changes, some subsystem maintainer reviews it, and Linus integrates it into the official tree. But there's a drawback: this only works if all developers have access to the same repository, on the same filesystem.
Aegis has got a distributed development model, but it doesn't offer the same repository tracking features as Bitkeeper. I don't know if this is relevant in the kernel context, IIRC Linus has complained more than once that the repository tracking (which links changesets to particular repositories/revisions) prevents him from automatically applying patches to the master repository.
It's a New EULA, so the old one did not mention it?
The solution is simple: continue to use your existing version.
The old EULA is revoked automatically as soon as Bitmover changes the Bitkeeper test suite so that the old version no longer passes it. In essence, this means that Bitmover can revoke old licenses at any time.
IANAL, but I know I can't rely on Bitkeeper (the vendor doesn't want me to, obviously). Maybe the commercially sold version is different, I don't know.
Bitkeeper is probably really nice software, so we can only hope that Red Hat (or someone else) buys Bitmover one day and licenses Bitkeeper under the GPL.
Currently, we don't know if the PPTP bug is real or a fake. Anyone can write an advisory like this, and there is no way you can tell if they tell the truth or not, unless you look carefully at the source code.
Okay, maybe you can confirm that their claim is true using some black box testing. Unfortunately, the guys with the unlimited time budget aren't the good ones, usually.
I don't understand the purpose of this advisory, really (at least not from a technical perspective). I don't think anyone has got a policy to disable any services based on such information. Microsoft won't admit that there is a problem until they have got a some fix. The bad guys will work overtime to discover the exact nature of this security defect, and the good guys will work overtime as usual, but are busy with other issues.
What does SQL have that cut/paste/grep/join don't besides tedious syntax?
Transactions? Indexes?
Hasn't Microsoft promised the same thing for Windows?
Look where we are now. Everyone's a sysadmin, installing operating system patches, and there's nobody with some clue to ask if anything goes wrong.