On Apr 10, 2019, at 12:17 PM, Brian Goetz <[email protected]> wrote: > > This is a fine technique for defending against such an attack (as is, don't > publish constructors that would let callers create the Gi objects.) And I'm > fine saying "if you want protection, add it."
Good. > I think Remi's concern is not that there is no defense, (Well, there is no defense until we implement the def-site atomicity declaration.) > but that authors might not realize that defense is needed, and might forget > to defend themselves. We need to add tearing to the various documents that security folks read. > (Or, a too-clever maintainer might put `inline` on a class that they don't > realize is being used as a capability token.) This suggests that we should add the "non-inline" keyword, so that an author who has a good reason *not* to make a class inline, can advertise the decision in a checkable manner. — John P.S. I have *often* wished for a "non-public" keyword; you can find my string "/*non-public*/" over 100 times in the code for java.lang.invoke classes, to prevent a too-clever maintainer from accidentally adding to a public API. (Likewise, "non-final" on variables which might otherwise be final. That would be a nice problem to have.)
