[e-lang] Why is javax.swing.ActionEvent.getActionCommand() suppressed? (and a CapDesk bug)
daw at cs.berkeley.edu
Fri Mar 7 00:41:43 EST 2008
Kevin Reid writes:
>javax.swing.ActionEvent.getActionCommand() appears to be necessary to
>tell which of the Cancel or Open/Save buttons the user pressed in a
>Why is this method suppressed?
I don't know. I don't see off-hand what the problem would be.
>I mentioned it to Dean Tribble and he
>thought there might have been some sort of information-leak or
>spoofing problem (though I don't see how the latter could happen),
>and that this came up during the DarpaBrowser review.
There is a paragraph in the DarpaBrowser review about
javax.swing.Action, but it's talking about something different.
We identified several risks associated with the javax.swing.Action
interface, which encapsulates the ability to perform certain user
interface actions (such as a cut-and-paste operation). Many classes
have getAction() and getActions() methods allowed, which might leak a
surprising capability to invoke one of these actions to the malicious
renderer. Similarly, many classes have setAction() and setActions()
methods allowed, which might allow a malicious renderer to change the
action associated with a user interface event and thereby change the
behavior of some trusted interface. We did not have time to look at
all code paths for all possible attacks, but we are worried about the
risk of exposing these capabilities to a malicious renderer: thus,
this is not a known risk, but rather is a ârisk of the unknownâ. We
suggest that these methods should be suppressed unless there is a
convincing argument that they are safe.
The link to the corresponding bug report doesn't work any more,
and I can't find E's current bug database to see if the bug database
entry contains any more information on this issue.
More information about the e-lang