fix: missing serialVersionUID for serializable classes #963
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
In file: in 11 files there are some serializable classes but they do not contain any serialVersionUID field. The compiler generates one by default in such scenarios, but the generated id is dependent on compiler implementation and may cause unwanted problems during deserialization.
The Role of serialVersionUID:
The primary role of serialVersionUID is to provide version control during deserialization. When deserialize an object, the JVM checks whether the serialVersionUID of the serialized data matches the serialVersionUID of the class in the current classpath. If they match, the deserialization proceeds without issues. However, if they do not match, programmers encounter InvalidClassException.
As, serialVersionUID servers the purpose of version control of class during serialization-deserialization, without a serialVersionUID, we risk breaking backward compatibility when making changes to classes, which can lead to unexpected issues and errors during deserialization.
Sponsorship and Support:
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.