The GitHub Actions job "Java CI" on commons-io.git/commons-io-val-obj-in-stream.patch has failed. Run started by GitHub user raboof (triggered by raboof).
Head commit for run: 3a370c0072a6d5417e6a6bfce2ee7cc4f2001d6b / Arnout Engelen <[email protected]> fix: confusing semantics for ValidatingObjectInputStream Before Commons IO 2.21.0: * Rejecting an interface had no effect * Rejecting a class would reject objects of all subclasses as well * Accepting an interface had no effect * Accepting a class would accept objects only if all superclasses were accepted as well After Commons IO 2.21.0: * Rejecting an interface had no effect on regular objects, but would reject proxy classes implementing that interface * Rejecting a class would reject objects of all subclasses as well * Accepting an interface had no effect on regular objects, but would accept proxy classes implementing that interface * Accepting a class would accept objects only if all superclasses were accepted as well That seems rather inconsistent. The logic change in this PR makes things slightly more consistent, but is a backwards-incompatible change (since it means applications using an allowist but not including the interfaces in it would stop accepting previously-accepted objects). It seems generally odd that allowlisting a class will not actually accept it without additionally accepting its superclasses (and implemented interfaces). Perhaps ValidatingObjectInputStream should either not take into account interfaces/superclasses at all, or do so in a more sophisticated fashion. Before making decisions we should also investigate how JVM11's ObjectInputFilterConfig behaves. That may inform what would make sense for us, and it would be good to document the differences. Co-Authored-By: Gary Gregory <[email protected]> Report URL: https://github.com/apache/commons-io/actions/runs/27556847760 With regards, GitHub Actions via GitBox
