Class File error handling for users

[-]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240514/a4b34555/attachment.htm>