Re: [Fed-Talk] Java for OS X 2013-003 and Mac OS X v10.6 Update 15
Re: [Fed-Talk] Java for OS X 2013-003 and Mac OS X v10.6 Update 15
- Subject: Re: [Fed-Talk] Java for OS X 2013-003 and Mac OS X v10.6 Update 15
- From: Dan Beatty <email@hidden>
- Date: Thu, 18 Apr 2013 11:02:17 -0700
- Thread-topic: [Fed-Talk] Java for OS X 2013-003 and Mac OS X v10.6 Update 15
Title: Re: [Fed-Talk] Java for OS X 2013-003 and Mac OS X v10.6 Update 15
Greetings Peter and gang,
I have to agree with both you and David on this issue. On the one hand, every developer from an IEEE Certified Software Development Professional (CSDP) and licensed software engineers to lowest of the low most likely understands the need for their software to act as a good citizen. Likewise, support from users, customers, administrators, stakeholders, etc is also critical. Although, we have a class of charlatans whose methods are trial and error. Those charlatans out there are known as hackers.
As you pointed out, the Java security model when interfacing with its hosts security model needs to be a good citizen. In the case that most Apple Developers use Java for, this is simplified by sandbox behavior of the Trusted Mach-UNIX kernel on which OSX is built. This applies to both stand alone and network applications. Most developers want these applications to exercise a limitation when it comes to direct communication within the file system or OS itself. Otherwise, that is a whole series of test cases that have to come into play. That spells nasty business and risk. An example of that risk are Applets like WebStart. They have a direct connection to the OS via the browser.
The most prominent of the Java developers in Apple’s midst were not really in any kind of danger. In particular, the WebObject developers product contact with Safari through the web not the file system. The vulnerability introduced in Java 6 and 7 was through its WebStart component. This was literally a case of an product that had no support what so ever (community or corporate). The consequence was that a large developer and consumer base of this technology could wreak havoc quickly. This havoc spread blame to Apple, developers, and even JavasScript that had nothing to do with the problem. In fact, _javascript_ is not Java and was fostered to satisfy the very need that the antiquated Java framework was providing.
This is an example of where Oracle needs to take a lesson from Apple. I would not want to see Java done away with. It is a powerful language built up by its frameworks over the period of two decades. Like its parent Objective-C, Java grew from the notion of its objects and learned the same lessons from NeXT about frameworks. The one lesson that they are learning now is that either you support a framework, hire or encourage someone to do it for you, or kill it. Apple learned this lesson and could teach. As Apple’s customers complain, chances are they will. Like all companies, Oracle will have to learn it for themselves.
V/R,
Daniel Beatty, Ph.D.
Computer Scientist, Detonation Sciences Branch
Code 474300D
1 Administration Circle M/S 1109
China Lake, CA 93555
email@hidden
(LandLine) (760)939-7097
(iPhone) (806)438-6620
On 4/17/13 8:54 AM, "Link, Peter R." <email@hidden> wrote:
Apple has control over what it supplies. As such, they make sure everything they supply works securely together. Java, something you work on all the time, is a secondary operating environment which Apple now has no control over. This is why they aren't supplying it in the standard distribution. As for Perl, Apple supplies programming aids within OSX and Xcode and allows individuals to install their own software at their own risk. In the early days, Apple wrote its own JRE because Sun didn't know how to incorporate it into Apple's security structure. Without starting a war, unix has limited controls over what it can and can't do and unix software is generally supplied that way. This is fine for people writing their own stuff but not for the consumer market, which is what Apple is all about. If you want to write software that works for you, that's fine, but remember all those other people out there who are relying on you, the software author, to package that software so it doesn't create a vulnerability or work around the established security structure.
If Oracle actually saw OSX as being anything more than a consumer OS, they would have ported their current database products (last one was 10.2 I believe, which isn't even listed on their site anymore). I suggest OSX is at the bottom of their list of OSes to support on anything. HP-UX and AIX are supported before OSX.
Yes, the current problems are in the Java browser plugin but Java implementations don't have to adhere to Apple's CDSA/CoreCrypto standards if they don't want to and that's what bothers me. Java was created to be its own operating system that could run anywhere. As such, it has its own environment, which can cause problems interacting with the host OS.
On Apr 17, 2013, at 8:31 AM, David Solin <email@hidden>
wrote:
That's quite a leap. That's like saying that you won't be able to run a Perl script on OSX because Apple doesn't distribute its own version of Perl. Apple has control over what apps are available on iOS because nothing gets on iOS unless it's available on the App Store, which Apple owns. Apple really has no such control over PCs.
In the early days of OSX, Apple wrote its own JRE because the platform was not a high priority for Sun. Now that OSX is much more popular, Oracle has plenty of incentive to support and maintain the Java runtime on that platform going forward. Apple no longer needs to spend time and effort in this area, and so they won't.
In terms of who is responsible for a security vulnerability... it is always quite clearly the software author. These are problems with the implementations of Java browser plug-ins, not flaws in the language specification itself.
On 4/17/2013 9:53 AM, Link, Peter R. wrote:
Shawn never talks directly about anything Apple is planning for the future (properly so) but I see his comments as giving a clear indication of Apple's future concerning Java. Apple is not going to pursue the continued operation of Java on OSX, that's up to Oracle to provide it and users to install and use it. Reading into this, I see Apple ultimately dropping Java support the same way they dropped Flash on iOS. It's not a necessary application environment for OSX and actually conflicts with OSX's security model (just like Flash). Shawn might reply saying I'm taking his comments too far but look at what's been happening with Java. Every time Java has a vulnerability, Apple is the one who takes the heat, not Oracle. Analysts, security experts, bloggers all point the finger at Apple instead of where it belongs. Apple has every right to make sure it keeps its software clean and I see their change in how Java is delivered as being the first step in removing Java for OSX.
Of course, I need Java running on my work computer because we have applications that require it.
On Apr 17, 2013, at 7:28 AM, Shawn Geddis <email@hidden> wrote:
On Apr 17, 2013, at 9:51 AM, Joel Esler <email@hidden> wrote:
Shawn, I think the implied question was, when is Apple going to move past 6? Oracle is on 7 now.
I think Java should die in a glorious fire, but the question remains.
Joel,
I understood that and thought it was clear in my statement.
"Oracle owns and manages Java, not Apple."
Starting with Java 7, Oracle has taken over 100% responsibility for Java on OS X. Are people not aware of this ?
To answer your question specifically,
" when is Apple going to move past 6?"
.... Well, never, since Oracle controls all updates and distribution of Java 7 and later….
Peter Link
Cyber Security Analyst
Cyber Security Program
Lawrence Livermore National Laboratory
PO Box 808, L-315
Livermore, CA 94551-0808
email@hidden
The contents of this message are mine personally and do not reflect the views or position of the U.S. Department of Energy, Federal Government, National Nuclear Security Administration, Lawrence Livermore National Security, or Lawrence Livermore National Laboratory.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden