Exporting - the wrong default?

dalibor topic dalibor.topic at oracle.com
Tue Aug 2 11:49:01 UTC 2016



On 01.08.2016 16:04, David M. Lloyd wrote:
> On 08/01/2016 05:40 AM, dalibor topic wrote:
>> Is it safe to assume that all such involuntarily headache inducing
>> Slings and Stones are also kept under lock in non-public classes?
>
> Of course not, no more than it is safe to assume that such will be kept
> hidden in non-exported packages under the existing regime.

Great - I think we can agree that some inadvertently headache inducing 
classes might be public and some might be not.

Let's now consider two different scenarios, in which Sling and Stone are 
either public, or not, and denote the variants with a P or N prefix - 
PSling is a public Sling, while NStone is a non-public Stone, for example.

Let's also consider two defaults: permissive (i.e. all packages are 
exported) and fail safe (i.e. no packages are exported).

Permissive:
PSling + PStone can induce a headache, while the other three cases 
fortunately can not. So a mere 25% opportunity for a headache.

Fail safe:
none of the four cases induce a headache.

Let's now add reflection & setAccessible to the mix.

To make the example more plastic, let's hypothetically assume that the 
Sling is some kind of a universal reflector utility class, which has a 
method that kindly performs a reflective operation upon polite request, 
using setAccessible if necessary to access otherwise inaccessible 
members, while violating SEC05-J [0]. Let's also assume that the Stone 
has some other potentially headache inducing problem.

Again, no headache occurs in the Failsafe case, because no packages are 
exported, while at the same time in the Permissive case, both the 
PSling+PStone and PSling+NStone cases now can induce a headache.

Fortunately, the other two cases still do not, so that's a mere 50% 
opportunity for headache.

A coin toss, in other words.

Now let's consider the Fail safe default with developers optionally 
exporting packages containing Sling and Stone. Let's mark classes 
contained in an exported package with an X prefix, while those that 
aren't get an O.

The headache inducing cases are

XPSling+XPStone and XPSling+XNStone

while the other 14 cases are not.

While headaches can no longer be excluded, that's quite a bit better 
than a coin toss, or even just the initial permissive scenario without 
use of reflection & setAccessible in the Sling.

Of course, you can get to the same cases starting with a Permissive 
default and then restricting exports of the packages in question.

Yet, there is an interesting difference between the two scenarios:

a) in the fail safe default case you start at no risk of headache 
inducing combinations of Slings and Stones, and then can increase your 
risk of a headache occurring to a certain level by adding exports, while 
in the permissive case you start at a coin toss level of headache risk 
and have to remove exports to decrease it to the same level, and

b) regardless of how many Slings and Stones there are in the mix, you 
always start at no risk of headache inducing combinations of Stones and 
Slings in the fail safe default case, while adding further Slings and 
Stones to the mix makes your initial headache risk significantly greater 
than a coin toss in the permissive case.

cheers,
dalibor topic

[0] 
https://www.securecoding.cert.org/confluence/display/java/SEC05-J.+Do+not+use+reflection+to+increase+accessibility+of+classes,+methods,+or+fields

-- 
<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


More information about the jigsaw-dev mailing list