multi-def values vs. security, elucidated and solved

[John Rose]

On Apr 10, 2019, at 12:17 PM, Brian Goetz <brian.goetz at oracle.com> 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.)