On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon <micha...@openjdk.org> wrote:
>> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such >> as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the >> specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in >> 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the >> networking code. >> A limited number of exceptions are already hidden (restricted) by default. >> The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default >> mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property >> "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of >> exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means >> that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are >> excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in >> terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example FilteredExceptionBuilder / EnhancedExceptionBuilder. It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder. EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy() ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2910598238
