It's not too late for access control

[dalibor topic]

On 16.07.2016 09:18, Jochen Theodorou wrote:
> You seem to be talking about achieving a certain goal and doing that
> using the wrong mechanisms... What about features that exist only
> because you have been able to trick the API or the JVM?

In that case, I'd suggest first working on bringing the necessary 
features into the missing platform layers, and once they are available, 
migrating to them.

> Just as an example... because the JVM used to have a URLClassloader when
> starting, it was possible to add classes there at runtime and @Grab was
> born to make use of that. Now this is no longer possible, @Grab will no
> longer work on JDK9 in many many cases. Why is that technical debt?

When someone deliberately breaks out of the boundary of what's supported 
functionality in a platform, they consciously trade off the benefits of 
that action against the risk of their code falling apart further down 
the road.

In other words, the benefit needs to be sufficiently advantageous to 
allow them to invest a part of its gains in eliminating the problem 
before the risk eventually materializes, for example by working on 
introducing the feature in a supported way at the appropriate layer of 
the platform, and then migrating to it.

If the benefit isn't sufficiently advantageous for that, or if they fail 
to plan adequately to eliminate the risk, then they might have a problem 
in some version of the future. But the core problem is not that a risk 
they consciously undertook eventually materializes, it's with risk 
assessment and decision making - and it's an entirely human thing to not 
get quite right.

A nice, long read on that from a security perspective is here:
https://www.schneier.com/essays/archives/2008/01/the_psychology_of_se.html

In open source ecosystems, there is often an additional human factor - 
people responsible for making the trade offs may be long gone from a 
project (as well as the associated benefits), by the time the risk they 
consciously introduced into a piece of software materializes.

So tools for conscious risk (re-)assessment are important, such as 
jdeps, or -XX:+CheckEndorsedAndExtDirs, ... as is empathy.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment