Seal as many jars as practical via Maven manifest customization
Basics
Logistics
Basics
Logistics
Description
Environment
None
Activity
Show:
Philip Smart April 27, 2021 at 2:30 PM
It would probably be possible to parameterize 'name' in the following manifest section and push the entire jar plugin configuration to each plugin's parent:
That would add that information to every jar if it did not already have it (only really the case with oidc-commons, which only currently exposes the name and vendor etc. in the plugin module with the service information), which may not be a bad thing, but I am not sure.
Philip Smart April 27, 2021 at 2:04 PM
Updated the Maven archetype to include jar sealing in the parent.
Philip Smart April 27, 2021 at 1:48 PM
All > 1.0.0 plugins have sealed module jars.
Philip Smart April 27, 2021 at 1:47 PM
java-idp-plugin-totp plugin module is now sealed.
Philip Smart April 27, 2021 at 1:25 PMEdited
java-idp-plugin-scripting plugin modules are now sealed.
Pinned fields
Click on the next to a field label to start pinning.
Details
Details
Assignee
Philip SmartReporter
Scott CantorCreated September 17, 2020 at 2:26 PM
Updated April 27, 2021 at 2:30 PM
Basic testing suggests that sealing our jars will prevent some, though not by any means all, ways of subverting some of the assumptions we make about loading code, and is good hygiene in general for preventing accidental jar conflicts.
Notably though, many scenarios do not appear to be impacted by sealing, including the Java Services loader and almost certainly resource loading from the classpath, and those are a somewhat major source of risk themselves.