A solution to the final classes problem
hjohn at xs4all.nl
Sun Sep 2 00:58:45 PDT 2012
On 2/09/2012 08:58, Tom Eugelink wrote:
> On 2012-09-02 07:33, Randahl Fink Isaksen wrote:
>> I do not disagree with you – maybe some things need to be final. I
>> just think you cast too wide a net, that is all.
> Which again leads me to repost my question; Swing has no final classes
> what so ever, you can extend any component (even JFileChooser
> Swing also is the most used UI framework, so there is enough
> incentive. Is there any example of how this has ever been misused as a
> security leak? Or perhaps an example of how this could be used as a
> security leak, which would have been prevented had the classes been
> final (and is not easily done some other way)?
It's trivial enough to put the features that really need to be secure in
a seperate final class (to which the UI delegates), or even in final or
private methods. Perhaps this is what Swing is doing internally. Some
analysis is needed to make sure results from these methods donot get
used in non-final methods.
Not that I can think of any realistic example why a FileChooser should
be secure in the first place -- this is already handled at a lower
level. Even if it did allow you to select some dangerous file,
attempting to manipulate it would immediately throw a security exception.
In fact, most stuff involving the UI should be secured at a much lower
level because any control provided by JavaFX can easily be recreated
using more basic controls.
I can imagine though that stuff like going full screen (with transparent
screens especially) and allowing one to open seperate windows would need
to be stuffed behind a security check. There's very little stopping you
to create an exact look-a-like of some password dialog, or even some
website + password entry fields. It does not necessarily have to
compromise your local machine to be a security issue...
More information about the openjfx-dev