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
