Taking a note from RISC OS and using AppDirs, this is probably *the* most intuitive packaging system in existence--at least with the current prevalence of the desktop-metaphor user interface. The same concept is also used by Apple and all the NeXTstep derivatives to great effect.
But as usual, never let it be said that a proven and effective mechanism for user interaction would be adopted by the Linux community.:)
Re:Easier way to colonize the universe
on
Interstellar Ark
·
· Score: 1
1. FIPS 140 validations taking a long time is not unusual.
2. OpenSSL was validated as *source*. All other FIPS 140 validations are of *object code* or devices. This is the first cryptomodule to be validated in source form and contributed to the time taken to validate.
3. The OpenSSL original cert was suspended because there was a small bit crypto code that resided outside the security boundary. Confusion between sponsor, lab, and NIST contributed to the suspension. See #2.
4. Claims of vendor FUD are overblown. NSS, another Open Source cryptomodule, already has FIPS 140-1 certification (for version 3.6; 3.11 will be entering FIPS 140-2 eval soon).
"There are billions of dollars being spent on studies to show that global warming is our fault."
No, there is money being spent on studies to find out *if* and *why* the climate is changing. This is not the same as paying someone for a *specific result*.
"Well, imagine that you're a scientist being paid by the Sierra club to do global warming research, and you turn around and say to them "well, sorry guys, but it turns out all this global warming is actually just a product of increased solar activity". Or you're a scientist hired by greenpeace to research the dangers of nuclear reactors, and you turn around and tell them "gee guys, it looks like Nuclear power is actually the most viable and least polluting source of energy we have!". What do you think will happen?"
They'll say "OK, we won't be renewing your grant next year. Thanks for all your hard work," and then I'll use the published research to get another position somewhere else.
"The truth is that if you attempt to find evidence that man made global warming isn't happening you're going to end up causing yourself endless problems in academic, political and social circles and many people are not going to try because the cost is to large."
Sorry, I'm going to call bullshit on this. Because *if* you succeed, the payoff is even larger: you *will* be hailed as the world's preeminent climatologist.
"Why perms get mangled is beyond me, I don't seem to have that problem on my Linux systems..."
Mostly this is because some developers insist on using brain-dead installers, even when a proper appdir is all that's needed. I even had one installer that did a chmod 0777 on/System/Library/StartupItems...*not* a good idea.
Very interesting book. One of the interesting tidbits was they figured out that an Orion burning out of *orbit* would result in significant fallout at ground level--enough so that they could estimate the additional number of cancer deaths--and this was one reason among many why the thing never got built. To be safe to Earth-bound life, Orion would have be launched from the Moon (how to build one *on* the Moon is left as an exercise for the reader:).
If I teach a thing, and a large portion of my students go out and do evil with it as justification, should I not have been more thorough in my instruction?
If my ideas lend themselves to the commission of evil, do I not bear some responsibility?
"Are the drug companies spending money on advertising for fun, or is it with the aim of producing a return? Presumably, they are aware of the economics of their field and know the balance for return on R + D, and return on advertising. Also, genuine question, do you have the figures to verify this statement? I have an interest in this anyway, so i'm not just trying to undermine your argument."
Also, several studies on direct-to-consumer prescription drug advertising have been published in JAMA of which I've read some abstracts, but I don't have an online JAMA subscription so I can't read 'em unless I go to the library.
"You claim that businesses would be idiots not to jump at the opportunity. There must be a lot of idiots out there -- all the press I'm reading says that business isn't exactly jumping at the chance to move to Vista."
Neither are governments. Office DRM doesn't play with X.509 PKIs at all, which is what everyone is heavily invested in. Further, while MS likes to make it sound easy to set up a PKI to support their DRM solutions, it really isn't--especially not when you start talking about all the real operational scenarios, like key escrow and recovery, offline functions, remote use, etc.
Actually, it is. Securing the page and hibernation files are as important as the data residing elsewhere on the disk. "Data at rest" refers to sleeping systems as much as powered down systems. This is why EFS doesn't suffice by itself to meet the OMB mandate for FDE; EFS doesn't protect page or sleep files, while FDE solutions work at the FS driver level and can do so (properly configured, of course).
I remember a previous time this arose, back in 1999 in a discussion with the Kerberos PM at Microsoft. It had occurred to me on the plane out to Seattle that MS's new support for power management--even on servers!--put Kerberos tickets at risk if the system was put to sleep. It was a fun conversation: "Tickets are held in LSA memory, right?" "Yes." "And as part of its protections, LSA memory is never swapped out to disk, right?" "Yes." "What happens when the system goes to sleep?" "... We'll get back to you on that."
As others have noted, the *real* answer is "Stop using easily stolen single factor authentication credentials, dumbass!" Smartcard + PIN is my choice (I'm not a biometric fan; too easy to spoof still).
Bingo. This was a topic of discussion at the SDC meetings. The consensus was: 1) don't do that, and 2) if you *must* do that, your org will have to ask for an exemption from policy.
"The Air Force currently requires ( in addition to the use of a "Smart Card" plugged into the machine to gain access ) a 15 char password consisting of 3 caps, 3 lower, 3 numbers, and 3 special char ( the rest is up to the user ), no proper names, dictionary words, more than 3 letters or numbers in sequence ( back or forward ), must not be the same or simular to your last 25 passwords, and you must change it every 90 days."... for admin accounts. And it's 60 days now. Go reread your NOTAMs.:) MAJCOM requirements are allowed to be more stringent, but the baseline is 9-char for users and 15-char for admins, with a 60-day cycle.
The 15-char min for smartcard-exempted user accounts is coming, though. It was like pulling teeth to get it, let me tell you.
The built-in FileVault on OS X is pretty good. It's not full volume (it's per home directory), but since on OS X all user data is in the home directory anyway that should be less of a concern. Basically, FileVault creates an encrypted disk image, copies the homedir into it, and erases the homedir. The disk image bulk key is wrapped with a key derived from the user's password, and with the recovery credential. At login, the encrypted disk image is mounted over the user's homedir and away we go.
In re: enterprise management, FileVault recovery credentials are actually an RSA private key and a certificate stored in the System's FileVault keychain. While a recovery *password* is used, the password *only* unlocks the RSA private key. The certificate is used to wrap each disk image's bulk key, and the RSA private key is used to unwsrap it. This is actually very neat, and here's why:
An admin creates a single recovery credential on one machine. He copies the FileVault keychain to secure media and stores it away. Then he *deletes the RSA private key* from the FileVault keychain. New FileVaults can still be created because the certificate is still there. This stripped-down FileVault keychain is then deployed to systems in the enterprise (pick your poison here; it's *just a regular file*), and users can turn on FileVault at will.
If you do it this way, you now have a single recovery credential to manage for the entire organization. No actual recovery key exists on the system, so there's no chance an intruder can get access to the encrypted images (assuming they're unmounted) by exploiting the recovery credential. But an admin can recover FileVault users simply: log in, copy the master FileVault keychain (the one with the RSA public key in it) over the existing one, and do a recover operation.
Note also that OS X can encrypt the page file as well. It's on the Security prefpane separate from FileVault.
Current hardware disk encryptors are generally a little bulky for laptops, and the solution has to be fitted to deployed hardware *now* vs. at the next tech refresh (which is typically on a 3-year cycle). Desktops are a lower priority at the moment.
Plus, I've not yet seen a hardware disk encryptor that supports CAC authentication.:)
DoD CACs have three key pairs; two for signing operations and the third for encryption. The encryption key is escrowed at generation to allow recovery by both user (when getting a new set of keys) and by law enforcement. It's the encryption key that will be used for FDE, generally by wrapping the bulk encryption key. Additional administrator keys are not strictly necessary where the CAC encryption key is being used to wrap the bulk volume encryption key, but the ability is desirable from an operational point of view. FWIW, the admin keys will be CAC keys as well, anyway.
It's understood that it's a requirement to be able to boot the system *without* admin involvement--it might be the admin you're investigating, or LE is worried about alerting the investigation target. That's why the CAC requirement is there, among a couple of other good reasons (for example, strong identification of who booted the system).
FWIW, it's fun to see things I work on show up in/.:)
"In short, Communism works. What it doesn't do is scale."
Communism can scale up to a village, but it requires an economy of abundance rather than an economy of scarcity to go any larger under a naive model. Unfortunately the world of physical things (with the exception of certain regional ecologies) is generally the latter.
My take is that most communist leaders understood this--thus the soviet system, which focused on village councils making decisions on production and distribution at the local level. What they were missing was the insight needed to stitch these little communes into an effective national economy. Perhaps this is an insoluble problem, but I can't say for certain that it's an area that's even been investigated in detail by economists; the Red Scare and Cold War attitudes in the West pretty effectively shut down any ideas that might possibly validate any economic system that wasn't laissez-faire Capitalism.
"The only way you can enforce Communism is at the point of a gun."
Incorrect. Primitive societies often take on economic models that can accurately be called communist without any threat of internal violence required to maintain internal stability (some of societies, still in existence today, are remarkably stable, with histories for thousands of years). In modern societies, sub-groups often voluntarily form communist economic groups--I grew up near a Christian commune that's been in operation since the 1950's, though it can be argued that the religious nature of that group was itself a form of authoritarianism.
The potential of the cell processor architecture is significant. Once developers figure out how to make optimal use of it it could potentially take games to a new level (think realistic physics, better AI, a better online experience, etc..).
Concomitant with that we should also think "longer development cycles and more expensive games." I think these will go hand in hand with developers trying to push the envelope on the Cell.
Slashdot Mirror
Taking a note from RISC OS and using AppDirs, this is probably *the* most intuitive packaging system in existence--at least with the current prevalence of the desktop-metaphor user interface. The same concept is also used by Apple and all the NeXTstep derivatives to great effect.
:)
But as usual, never let it be said that a proven and effective mechanism for user interaction would be adopted by the Linux community.
_Voyage from Yesteryear_, James P. Hogan, 1982.
What good would it do you if the AES implementation was just *wrong*? Or if the crypto library processes the key in unprotected memory?
That's what validation gets you.
1. FIPS 140 validations taking a long time is not unusual.
2. OpenSSL was validated as *source*. All other FIPS 140 validations are of *object code* or devices. This is the first cryptomodule to be validated in source form and contributed to the time taken to validate.
3. The OpenSSL original cert was suspended because there was a small bit crypto code that resided outside the security boundary. Confusion between sponsor, lab, and NIST contributed to the suspension. See #2.
4. Claims of vendor FUD are overblown. NSS, another Open Source cryptomodule, already has FIPS 140-1 certification (for version 3.6; 3.11 will be entering FIPS 140-2 eval soon).
Too bad for your view of the world that this isn't how the Sierra Club funds research.
Why isn't the Nokia N800?
"There are billions of dollars being spent on studies to show that global warming is our fault."
No, there is money being spent on studies to find out *if* and *why* the climate is changing. This is not the same as paying someone for a *specific result*.
Yes, your personal lack of skin cancer completely refutes all ozone measurements over the Antarctic. You dumbass.
"Well, imagine that you're a scientist being paid by the Sierra club to do global warming research, and you turn around and say to them "well, sorry guys, but it turns out all this global warming is actually just a product of increased solar activity". Or you're a scientist hired by greenpeace to research the dangers of nuclear reactors, and you turn around and tell them "gee guys, it looks like Nuclear power is actually the most viable and least polluting source of energy we have!". What do you think will happen?"
They'll say "OK, we won't be renewing your grant next year. Thanks for all your hard work," and then I'll use the published research to get another position somewhere else.
Duh.
"The truth is that if you attempt to find evidence that man made global warming isn't happening you're going to end up causing yourself endless problems in academic, political and social circles and many people are not going to try because the cost is to large."
Sorry, I'm going to call bullshit on this. Because *if* you succeed, the payoff is even larger: you *will* be hailed as the world's preeminent climatologist.
"Why perms get mangled is beyond me, I don't seem to have that problem on my Linux systems..."
/System/Library/StartupItems...*not* a good idea.
Mostly this is because some developers insist on using brain-dead installers, even when a proper appdir is all that's needed. I even had one installer that did a chmod 0777 on
Read this if you haven't already:
S paceship/dp/0805059857
:).
http://www.amazon.com/Project-Orion-Story-Atomic-
Very interesting book. One of the interesting tidbits was they figured out that an Orion burning out of *orbit* would result in significant fallout at ground level--enough so that they could estimate the additional number of cancer deaths--and this was one reason among many why the thing never got built. To be safe to Earth-bound life, Orion would have be launched from the Moon (how to build one *on* the Moon is left as an exercise for the reader
If I teach a thing, and a large portion of my students go out and do evil with it as justification, should I not have been more thorough in my instruction?
If my ideas lend themselves to the commission of evil, do I not bear some responsibility?
"Are the drug companies spending money on advertising for fun, or is it with the aim of producing a return? Presumably, they are aware of the economics of their field and know the balance for return on R + D, and return on advertising. Also, genuine question, do you have the figures to verify this statement? I have an interest in this anyway, so i'm not just trying to undermine your argument."
l
& q=direct+to+consumer+prescription+drug+advertising &ie=UTF-8&oe=UTF-8
http://www.newstarget.com/010315.html
Also, several studies on direct-to-consumer prescription drug advertising have been published in JAMA of which I've read some abstracts, but I don't have an online JAMA subscription so I can't read 'em unless I go to the library.
Also some good stuff here:
http://www.fda.gov/cder/ddmac/globalsummit2003/
http://www.fda.gov/fdac/features/2003/203_dtc.htm
All these from this google search:
http://www.google.com/search?client=safari&rls=en
"You claim that businesses would be idiots not to jump at the opportunity. There must be a lot of idiots out there -- all the press I'm reading says that business isn't exactly jumping at the chance to move to Vista."
Neither are governments. Office DRM doesn't play with X.509 PKIs at all, which is what everyone is heavily invested in. Further, while MS likes to make it sound easy to set up a PKI to support their DRM solutions, it really isn't--especially not when you start talking about all the real operational scenarios, like key escrow and recovery, offline functions, remote use, etc.
Actually, it is. Securing the page and hibernation files are as important as the data residing elsewhere on the disk. "Data at rest" refers to sleeping systems as much as powered down systems. This is why EFS doesn't suffice by itself to meet the OMB mandate for FDE; EFS doesn't protect page or sleep files, while FDE solutions work at the FS driver level and can do so (properly configured, of course).
I remember a previous time this arose, back in 1999 in a discussion with the Kerberos PM at Microsoft. It had occurred to me on the plane out to Seattle that MS's new support for power management--even on servers!--put Kerberos tickets at risk if the system was put to sleep. It was a fun conversation: "Tickets are held in LSA memory, right?" "Yes." "And as part of its protections, LSA memory is never swapped out to disk, right?" "Yes." "What happens when the system goes to sleep?" "... We'll get back to you on that."
As others have noted, the *real* answer is "Stop using easily stolen single factor authentication credentials, dumbass!" Smartcard + PIN is my choice (I'm not a biometric fan; too easy to spoof still).
Bingo. This was a topic of discussion at the SDC meetings. The consensus was: 1) don't do that, and 2) if you *must* do that, your org will have to ask for an exemption from policy.
"The Air Force currently requires ( in addition to the use of a "Smart Card" plugged into the machine to gain access ) a 15 char password consisting of 3 caps, 3 lower, 3 numbers, and 3 special char ( the rest is up to the user ), no proper names, dictionary words, more than 3 letters or numbers in sequence ( back or forward ), must not be the same or simular to your last 25 passwords, and you must change it every 90 days." ... for admin accounts. And it's 60 days now. Go reread your NOTAMs. :) MAJCOM requirements are allowed to be more stringent, but the baseline is 9-char for users and 15-char for admins, with a 60-day cycle.
The 15-char min for smartcard-exempted user accounts is coming, though. It was like pulling teeth to get it, let me tell you.
The built-in FileVault on OS X is pretty good. It's not full volume (it's per home directory), but since on OS X all user data is in the home directory anyway that should be less of a concern. Basically, FileVault creates an encrypted disk image, copies the homedir into it, and erases the homedir. The disk image bulk key is wrapped with a key derived from the user's password, and with the recovery credential. At login, the encrypted disk image is mounted over the user's homedir and away we go.
In re: enterprise management, FileVault recovery credentials are actually an RSA private key and a certificate stored in the System's FileVault keychain. While a recovery *password* is used, the password *only* unlocks the RSA private key. The certificate is used to wrap each disk image's bulk key, and the RSA private key is used to unwsrap it. This is actually very neat, and here's why:
An admin creates a single recovery credential on one machine. He copies the FileVault keychain to secure media and stores it away. Then he *deletes the RSA private key* from the FileVault keychain. New FileVaults can still be created because the certificate is still there. This stripped-down FileVault keychain is then deployed to systems in the enterprise (pick your poison here; it's *just a regular file*), and users can turn on FileVault at will.
If you do it this way, you now have a single recovery credential to manage for the entire organization. No actual recovery key exists on the system, so there's no chance an intruder can get access to the encrypted images (assuming they're unmounted) by exploiting the recovery credential. But an admin can recover FileVault users simply: log in, copy the master FileVault keychain (the one with the RSA public key in it) over the existing one, and do a recover operation.
Note also that OS X can encrypt the page file as well. It's on the Security prefpane separate from FileVault.
Current hardware disk encryptors are generally a little bulky for laptops, and the solution has to be fitted to deployed hardware *now* vs. at the next tech refresh (which is typically on a 3-year cycle). Desktops are a lower priority at the moment.
:)
Plus, I've not yet seen a hardware disk encryptor that supports CAC authentication.
DoD CACs have three key pairs; two for signing operations and the third for encryption. The encryption key is escrowed at generation to allow recovery by both user (when getting a new set of keys) and by law enforcement. It's the encryption key that will be used for FDE, generally by wrapping the bulk encryption key. Additional administrator keys are not strictly necessary where the CAC encryption key is being used to wrap the bulk volume encryption key, but the ability is desirable from an operational point of view. FWIW, the admin keys will be CAC keys as well, anyway.
/. :)
It's understood that it's a requirement to be able to boot the system *without* admin involvement--it might be the admin you're investigating, or LE is worried about alerting the investigation target. That's why the CAC requirement is there, among a couple of other good reasons (for example, strong identification of who booted the system).
FWIW, it's fun to see things I work on show up in
"In short, Communism works. What it doesn't do is scale."
Communism can scale up to a village, but it requires an economy of abundance rather than an economy of scarcity to go any larger under a naive model. Unfortunately the world of physical things (with the exception of certain regional ecologies) is generally the latter.
My take is that most communist leaders understood this--thus the soviet system, which focused on village councils making decisions on production and distribution at the local level. What they were missing was the insight needed to stitch these little communes into an effective national economy. Perhaps this is an insoluble problem, but I can't say for certain that it's an area that's even been investigated in detail by economists; the Red Scare and Cold War attitudes in the West pretty effectively shut down any ideas that might possibly validate any economic system that wasn't laissez-faire Capitalism.
"The only way you can enforce Communism is at the point of a gun."
Incorrect. Primitive societies often take on economic models that can accurately be called communist without any threat of internal violence required to maintain internal stability (some of societies, still in existence today, are remarkably stable, with histories for thousands of years). In modern societies, sub-groups often voluntarily form communist economic groups--I grew up near a Christian commune that's been in operation since the 1950's, though it can be argued that the religious nature of that group was itself a form of authoritarianism.
The potential of the cell processor architecture is significant. Once developers figure out how to make optimal use of it it could potentially take games to a new level (think realistic physics, better AI, a better online experience, etc..).
Concomitant with that we should also think "longer development cycles and more expensive games." I think these will go hand in hand with developers trying to push the envelope on the Cell.