Re:Sounds interesting, but I'm annoyed by the US c
on
Ash: A Secret History
·
· Score: 1
One half of the American population is below *median* intelligence. Quite a few more of us are below *average* intelligence. I've forgotten most of my high school math, but knowing the difference between median and mean is important.
Considering that the cost of an employee to a company is generally something like twice their salary, one megabuck will not support a dozen tech employees for a year in Connecticut. Maybe in New Delhi...
Darwin runs on x86. So I can't see how porting MacOS X to x86 could require more than a recompile, since everything above Darwin presumably uses Darwin-exported abstractions rather than fiddling with hardware directly.
You're missing quite a bit of the picture. Mach is a microkernel, it only provides a few simple services. Most Mach implementations use BSD code with some modifications to provide a POSIXish interface.
MacOS X Server only runs MacOS applications in the so-called Blue Box, that is, under emulation. Therefore, they run relatively slowly, and they don't get the benefits of preemptive multitasking, protected memory, etc.
One of the components that has delayed MacOS X for so long is the "Carbon" module, which will allow slightly modified and recompiled MacOS software to run as first-class citizens, if you will, able to take advantage of the modern features of OS X and not running under emulation.
Is the existence or non-existence of the ADK protected by the cryptographic hash? In other words, if you create your certificate with a non-vulnerable PGP program, no ADK can be added? That's implied by your post, but I want to be sure I understand correctly.
So the original certificate has to contain a (possibly empty) ADK packet for the exploit to work? And thus it has to have been generated by a version of PGP that supports ADKs and that buggily[0] includes the ADK packet in the unsigned portion of the certificate?
Sorry for posting misinformation on those *cough* key points.
Doesn't a shared library implement a form of encapsulation? I don't think your analysis is correct -- while explicit support for an OO principle in a language makes things easier, you can use OO techniques in any language. Certainly there are examples of encapsulation all over modern unix kernels.
You misread. PGP is not generating an ADK. PGP is *accepting* ADKs that are attached to public key certificates but not signed by the issuer of the certificate.
Here is the exploit sequence: you issue a PGP certificate, containing your public key. You may be not be running a version of PGP with the bug, it doesn't matter. Joe Evil attaches another public key to your certificate as an ADK, and passes it around. Someone who is running the vulnerable PGP uses your certificate to encrypt a message to you. However, they *also* make a copy encrypted with Joe Evil's public key! And they won't even know it unless they examined your certificate manually. Now Joe can read their message.
So the problem here isn't that PGP is attaching an ADK, but rather that someone could later attach an ADK and the tampering would be not detected by someone using the certificate to communicate with its issuer.
Inline assembler is bad except when it isn't. If you use Linux or FreeBSD, try looking at the output of "locate -i.s | grep src" for some examples of the latter case.
Naturally, apps programmers who use inline assembler should usually be shot, but there are parts of libc that would be slower without it, and for certain "glue" areas it can't be avoided.
Ah, I see. What is the functional difference between a primary and a secondary IDE controller? I wasn't aware of such a distinction.
My confusion here shows that I've spent more time working with DNS (where master/save are the new terms for what used to be called primary/secondary) than with IDE.;-)
This is a cute scenario, but does it have any basis in reality?
I was quite concerned the first time I had an NDA/non-compete shoved at me. I asked my father about it, because he's a lawyer, and he said they're rarely enforced. I don't know how current his information on that is, though, as that area of law is not his specialty.
Any actual corporate lawyers around here, or is that too much to hope for?
Ok, I read the article. I didn't see anything of substance in it -- it was just a bunch of Limbaugh-esque ranting, apparently because the Supremes made some decisions the authors didn't like.
Slashdot Mirror
One half of the American population is below *median* intelligence. Quite a few more of us are below *average* intelligence. I've forgotten most of my high school math, but knowing the difference between median and mean is important.
--
> A marketing company could not afford sending junk mail to an "old" address.
Nah, the size of their list is usually the selling point, so they have little motivation to keep it current or correct.
--
Considering that the cost of an employee to a company is generally something like twice their salary, one megabuck will not support a dozen tech employees for a year in Connecticut. Maybe in New Delhi ...
--
Endorphins aren't similar to caffeine, they're similar to opiates.
--
Somewhere in their vaults they should also have a (possibly out of date) version for Solaris, I think.
--
Darwin runs on x86. So I can't see how porting MacOS X to x86 could require more than a recompile, since everything above Darwin presumably uses Darwin-exported abstractions rather than fiddling with hardware directly.
--
You're missing quite a bit of the picture. Mach is a microkernel, it only provides a few simple services. Most Mach implementations use BSD code with some modifications to provide a POSIXish interface.
--
> I think OS X still uses Display PostScript, which is just as cool as regular Postscript.
I believe it actually uses something akin to PDF (in the same way that DPS is akin to PS).
--
Methinks OS X/x86 will happen only when Apple has some reason to think it won't instigate the cancellation of MS Office for Macintosh.
--
... with a little Paul Rand "NeXT" logo on it.
--
I have a complete system that I purchased from Micron, and I have only good things to say about it.
--
Following up to my own post: Here's a story on CNET. And one on Yahoo.
--
Does anyone know any real details?
--
MacOS X Server only runs MacOS applications in the so-called Blue Box, that is, under emulation. Therefore, they run relatively slowly, and they don't get the benefits of preemptive multitasking, protected memory, etc.
One of the components that has delayed MacOS X for so long is the "Carbon" module, which will allow slightly modified and recompiled MacOS software to run as first-class citizens, if you will, able to take advantage of the modern features of OS X and not running under emulation.
I hope this explains what you wanted to know.
--
Is the existence or non-existence of the ADK protected by the cryptographic hash? In other words, if you create your certificate with a non-vulnerable PGP program, no ADK can be added? That's implied by your post, but I want to be sure I understand correctly.
--
So the original certificate has to contain a (possibly empty) ADK packet for the exploit to work? And thus it has to have been generated by a version of PGP that supports ADKs and that buggily[0] includes the ADK packet in the unsigned portion of the certificate?
Sorry for posting misinformation on those *cough* key points.
[0] I say it's a word, so there.
--
Doesn't a shared library implement a form of encapsulation? I don't think your analysis is correct -- while explicit support for an OO principle in a language makes things easier, you can use OO techniques in any language. Certainly there are examples of encapsulation all over modern unix kernels.
--
You misread. PGP is not generating an ADK. PGP is *accepting* ADKs that are attached to public key certificates but not signed by the issuer of the certificate.
Here is the exploit sequence: you issue a PGP certificate, containing your public key. You may be not be running a version of PGP with the bug, it doesn't matter. Joe Evil attaches another public key to your certificate as an ADK, and passes it around. Someone who is running the vulnerable PGP uses your certificate to encrypt a message to you. However, they *also* make a copy encrypted with Joe Evil's public key! And they won't even know it unless they examined your certificate manually. Now Joe can read their message.
So the problem here isn't that PGP is attaching an ADK, but rather that someone could later attach an ADK and the tampering would be not detected by someone using the certificate to communicate with its issuer.
--
Inline assembler is bad except when it isn't. If you use Linux or FreeBSD, try looking at the output of "locate -i .s | grep src" for some examples of the latter case.
Naturally, apps programmers who use inline assembler should usually be shot, but there are parts of libc that would be slower without it, and for certain "glue" areas it can't be avoided.
--
Ah, I see. What is the functional difference between a primary and a secondary IDE controller? I wasn't aware of such a distinction.
;-)
My confusion here shows that I've spent more time working with DNS (where master/save are the new terms for what used to be called primary/secondary) than with IDE.
--
Er, I think you put in an extra power of two.
Two controllers, each controlling one master and one slave, makes a total of four.
--
This is a cute scenario, but does it have any basis in reality?
I was quite concerned the first time I had an NDA/non-compete shoved at me. I asked my father about it, because he's a lawyer, and he said they're rarely enforced. I don't know how current his information on that is, though, as that area of law is not his specialty.
Any actual corporate lawyers around here, or is that too much to hope for?
--
Ok, I read the article. I didn't see anything of substance in it -- it was just a bunch of Limbaugh-esque ranting, apparently because the Supremes made some decisions the authors didn't like.
--
No ... I was listening to some Tropicalia last night, Brazilian music from the late '60s, and you can't tell me you can't rock in Portuguese.
--
No, IP masquerading is really just a gratuitous terminology change -- I can do any of that stuff with natd or libalias-based software on FreeBSD.
--