Class File error handling for users

[Brian Goetz]

I think it would be worthwhile to try to characterize the sorts of validation that we do and do not perform, so that users don’t think “they caught error A but not error B” is purely a result of inconsistent implementation.  

> On May 14, 2024, at 7:57 PM, liangchenblue at gmail.com wrote:
> 
> Hello ClassFile API programmers,
> I noticed that recently ClassFile API has quite a few bugs caused by our minimal validation policies, such as JDK-8331940, JDK-8331655, JDK-8331320, JDK-8330684. They are mostly caused by us not defending against malicious values that conform to the CF structure (so they avoid IAE).
> 
> I believe our policy of minimal validation (i.e. only validating data that's required to build our API model, such as bci for Label, cp index + type for PoolEntry, etc.) is on the correct path for minimal performance impact. Yet the occurrences of these bugs may have an implication on user code, that users might frequently encounter such bugs like we did too, especially for bound attributes lazily reading from malicious class files and returning unsanitized primitive types.
> 
> As a solution to such problems, I recommend we put up a note in the package info of ClassFile API, telling users that they should sanitize input class files. Our API already took a step in this direction, that we throw IAE for structurally malformed class files; users should realize that such IAEs only happen with lazy expansion, and should perform extra validations and throw IAE to further validate correctness of Class Files.
> 
> Do you think this validation problem is valid? And if so, would this solution mitigate this issue? I don't think my solution is perfect and am open to input.
> 
> Chen Liang