Reads like a person who doesn't have to deal with managing patches and out-of-cycle fixes, with one public application let alone many, with just one customer let alone millions..
I think it's more a matter of the knowledge on how to use Java as an attack vector (and the inclusion into Java exploits into easy-to-use-kits) causing the anti-Java sentiment, not who owns Java.
And some of that sentiment is misplaced: These exploits are largely a client-side problem (e.g., browsers running Java applets or downloaded Java apps) brought on by the servers dishing the Java up not being properly secured and/or managed.
Java's a great language in terms of what it's brought to the forefront of application development - both in terms of standardizing what a language can offer (I still loathe the days of having to decide if I would roll my own containers or memory manager in 'C' vs. picking and paying for someone's 3rd party libraries) as well as the OO aspects it forces you to consider.
Tough to blame the "media" when good old economics + gov't misdirection play a large part of slanted reporting: When you lose the mainstream funding mechanism for solid investigative reporting (newspapers), and the public relies on the Internet style of reporting (skim what's in the news), well, you creating a nice opportunity to paint whatever you want..
Reading bytes of sound bytes @ whenever you boot up the newsreader.
funny real event: Co-worker could not get his email client to work. Connection is managed using SSL, and the tunnel setup was failing. The reported error was a certificate invalid. That didn't jive with the CA cert - it was issued a year ago and is good for like 20 years.
After looking and looking and looking: He realized his system date was set to 1/1/1980 - his CMOS battery was dead.. Jan 1 1980 is prior to the start of the validity period for the CA cert in use..;)
You've missed my point: UEFI offers another layer of defense. (And not withstanding, the O/S being adapted to make use of the secure loading, local attestation, etc. etc.) Make sense?
With respect to loading something new - unsigned - depends on how the O/S implements attestation, right? And it does *not* have to exclude one for the other. This is the big deal about UEFI - the difficulty of managing the (trusted) signing keys so that coders can readily deploy a new and/or updated set of code (let alone, test drive it in production!).
And you're absolutely correct on running PHP or Perl or..whatever - unless they do something like Java's sandbox security mechanism (which according to most sources is the #1 attack vector for online attacks). Then you just get another can of worms to defend.
It's the "thoroughly written" part that's hard. Secureboot adds another layer of defense to the O/S and applications it loads. Here's what makes it more difficult:
If the BIOS only allows the loading of "trusted" O/S - because it's been signed by a known key, and in turn, the O/S only allows the loading of trusted apps - because they are signed by known keys - then the compromise needs to become trusted in order to run. In other words, unless the compromise is using a trusted key to sign the malware, the O/S will reject loading the stuff.
Thus, just tweaking some bits is no longer adequate - you would now need to re-sign whatever you've changed.
And this problem - having to sign code with trusted keys - is at the heart of the petition cited by this poster. It's NOT about secure boot loading (which is actually a good thing); it's about the lack of freely available keys to sign open source code with.
*LOTS* of people should get recognized for work related to crypto.
Then again - if you're any good at it, chances are there are groups who would rather you didn't get recognition.
The recommendation has merit regardless of the political motivation. The heart of the issue is how does one TRUST and verify the INTEGRITY of the download when its transported using XML.
What's frustrating is someone's inability to agree to rely on existing standards - there's simply no reason to spend more $$$ reinventing / resolving what's already solved.
Doesn't the government currently exchange XML-based information today? Isn't that information secured in such a manner that the provider (say, the contractor of the F-22) can be proven and the validity of the message confirmed?
Another side-show and the land of the free where matters such as paying people to entertain us is more important than paying people to educate us.
Nope, ya can't! However, for argument's sake, let's say you forgot to 'sudo vi/etc/hosts' for a moment, I would do the following (assuming *nix):
^Z (to suspend my vim session)
sudo chmod g+w/etc/hosts (assuming i'm a member of the group who can write this file)
fg (resume gvim session) :w! (force the write) :q
sudo chmod g-w/etc/hosts
cheers!
Slashdot Mirror
Reads like a person who doesn't have to deal with managing patches and out-of-cycle fixes, with one public application let alone many, with just one customer let alone millions..
I think it's more a matter of the knowledge on how to use Java as an attack vector (and the inclusion into Java exploits into easy-to-use-kits) causing the anti-Java sentiment, not who owns Java.
And some of that sentiment is misplaced: These exploits are largely a client-side problem (e.g., browsers running Java applets or downloaded Java apps) brought on by the servers dishing the Java up not being properly secured and/or managed.
Java's a great language in terms of what it's brought to the forefront of application development - both in terms of standardizing what a language can offer (I still loathe the days of having to decide if I would roll my own containers or memory manager in 'C' vs. picking and paying for someone's 3rd party libraries) as well as the OO aspects it forces you to consider.
Tough to blame the "media" when good old economics + gov't misdirection play a large part of slanted reporting: When you lose the mainstream funding mechanism for solid investigative reporting (newspapers), and the public relies on the Internet style of reporting (skim what's in the news), well, you creating a nice opportunity to paint whatever you want..
Reading bytes of sound bytes @ whenever you boot up the newsreader.
To try and use the collider and have to peel the onion to deal with the unknowns. Then again, could be the Laundry at work.. ;)
funny real event: Co-worker could not get his email client to work. Connection is managed using SSL, and the tunnel setup was failing. The reported error was a certificate invalid. That didn't jive with the CA cert - it was issued a year ago and is good for like 20 years.
After looking and looking and looking: He realized his system date was set to 1/1/1980 - his CMOS battery was dead.. Jan 1 1980 is prior to the start of the validity period for the CA cert in use.. ;)
You've missed my point: UEFI offers another layer of defense. (And not withstanding, the O/S being adapted to make use of the secure loading, local attestation, etc. etc.) Make sense?
With respect to loading something new - unsigned - depends on how the O/S implements attestation, right? And it does *not* have to exclude one for the other. This is the big deal about UEFI - the difficulty of managing the (trusted) signing keys so that coders can readily deploy a new and/or updated set of code (let alone, test drive it in production!).
And you're absolutely correct on running PHP or Perl or..whatever - unless they do something like Java's sandbox security mechanism (which according to most sources is the #1 attack vector for online attacks). Then you just get another can of worms to defend.
Huh? If you have to re-install *any* O/S, and the user has not backed up their files, UEFI does NOT make it worse.
It is absolutely the same.
It's the "thoroughly written" part that's hard. Secureboot adds another layer of defense to the O/S and applications it loads. Here's what makes it more difficult:
If the BIOS only allows the loading of "trusted" O/S - because it's been signed by a known key, and in turn, the O/S only allows the loading of trusted apps - because they are signed by known keys - then the compromise needs to become trusted in order to run. In other words, unless the compromise is using a trusted key to sign the malware, the O/S will reject loading the stuff.
Thus, just tweaking some bits is no longer adequate - you would now need to re-sign whatever you've changed. And this problem - having to sign code with trusted keys - is at the heart of the petition cited by this poster. It's NOT about secure boot loading (which is actually a good thing); it's about the lack of freely available keys to sign open source code with.
*LOTS* of people should get recognized for work related to crypto. Then again - if you're any good at it, chances are there are groups who would rather you didn't get recognition.
The recommendation has merit regardless of the political motivation. The heart of the issue is how does one TRUST and verify the INTEGRITY of the download when its transported using XML. What's frustrating is someone's inability to agree to rely on existing standards - there's simply no reason to spend more $$$ reinventing / resolving what's already solved. Doesn't the government currently exchange XML-based information today? Isn't that information secured in such a manner that the provider (say, the contractor of the F-22) can be proven and the validity of the message confirmed? Another side-show and the land of the free where matters such as paying people to entertain us is more important than paying people to educate us.
Nope, ya can't! However, for argument's sake, let's say you forgot to 'sudo vi /etc/hosts' for a moment, I would do the following (assuming *nix): /etc/hosts (assuming i'm a member of the group who can write this file)
:w! (force the write)
:q /etc/hosts
^Z (to suspend my vim session)
sudo chmod g+w
fg (resume gvim session)
sudo chmod g-w
cheers!