To ensure backward compatibility, Security components that implement Serializable should have a serialVersionUID.

Based on internal testing across a few dozen JVMs, it appears that the serialVersionUID is consistent for Security's components. As such, we can safely add the calculated serialVersionUID value to each class that is missing it during the 6.4.x maintenance cycle.

  • [x] #16274
  • [x] Produce list of Serializable classes missing serialVersionUID
  • [ ] Fail build when a Serializable class is missing a serialVersionUID
  • [ ] Consider adding an exclusion list for classes we don't support being serialized

When addressing a class that is missing its serialVersionUID, please do the following:

  1. Add the calculated serialVersionUID (IDEs can usually do this for you, or you can use serialver which ships with the JVM)
  2. In SpringSecurityCoreVersionSerializableTests, add the class and an example construction to the generatorByClassName map
  3. Run SpringSecurityCoreVersionSerializableTests#serializeCurrentVersionClasses.

  4. If successful, it will create a {className}.serialized file in config/src/main/resources/serialized:

    Run the other tests in SpringSecurityCoreVersionSerializableTests; the class should be added to the list in shouldBeAbleToDeserializeClassFromPreviousVersion, the class should no longer be in the output for listClassesMissingSerialVersion

    Commit the Serialiizable class(es) and SpringSecurityCoreVersionSerializableTests 5. If unsuccessful, it is usually because one of its members is not serializable. Find the unserializable member; file a ticket to ensure that it is made Serializable

You can also see the list of Serializable files by running:

./gradlew :spring-security-config:test --tests "*MissingSerialVersion*" -Pserialization

Comment From: jzheaux

This is a duplicate of https://github.com/spring-projects/spring-security/issues/16276