On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and understand it in order to instrument
it.
Absolutely. But that is exactly the work OpenJDK maintainers are required to do
today to support something most
people want better alternatives for at the expense of those better alternatives
and other work.
The Principle of Least Privilege reduces the consequences resulting from
attacks that penetrate external security defenses, whether by social
engineering, failure to sanitize input, protocols, or platform
vulnerabilities.
After many years of pain, JDK development work has not been wasted, I
for one am grateful for the development efforts and thoughts put into
securing the JVM. It is expensive and now your employer has decided
they no longer wish to carry this expense, pushing it downstream.
Java has a proven and well tested security API, it's flaws are generally
well understood.
At sometime in the future, Java's internal security defenses will be
removed, and new code will no longer perform permission checks, so any
breaches of external defenses will result in a JVM being Pwned.
After considering the proposals for new Security API, I have decided
that the Java 1.8 to Java 1.17 versions will be the most suitable as it
has the best well developed and understood security architecture,
requiring little further development work.
The new proposals arising from this JEP present a significant
development upgrade cost, and these new API's that we need to use for
building new security architecture around, won't be battle hardened, are
experimental and haven't passed the test of time.
My assessment is the cost to upgrade is too high and far too great a
risk in this instance, the least cost and safest option is to stay with
well proven, deployment tested, high performance, hardened existing API's.
I wish the OpenJDK project success in their future endeavors. We will
try to support later Java versions in Service implementations, similar
to other languages, however these will not be able to consume other
services. This may enable users to take advantage of later language
features. However we will always require the use of Java 1.8 to 1.17 as
service consumers.
I am grateful for the efforts, which appear to be thought of as wasted
efforts or bad money, however this time spent addressing security
issues, will leave the series of Java versions from 1.8 to 1.17 as some
of the most secure versions of any software platform, as an asset of
significant value to those who value security.
Thank you.
Peter Firmstone.
