Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JENKINS-70066: Fix null check of parameters #134

Merged
merged 1 commit into from
Dec 4, 2024

Conversation

mtughan
Copy link
Contributor

@mtughan mtughan commented Dec 4, 2024

The @DataBoundConstructor for ScriptlerBuilder takes a list of parameters for the given script. It was annotated as @NotNull, but Descriptor.bindJSON could occasionally pass null for the parameters list. Fix this by annotating the parameter as @CheckForNull and performing the appropriate null checks.

Testing done

Static analysis only.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

@mtughan mtughan self-assigned this Dec 4, 2024
The `@DataBoundConstructor` for `ScriptlerBuilder` takes a list of
parameters for the given script. It was annotated as `@NotNull`, but
`Descriptor.bindJSON` could occasionally pass `null` for the parameters
list. Fix this by annotating the parameter as `@CheckForNull` and
performing the appropriate null checks.
@mtughan mtughan force-pushed the parameters-null-check branch from de21387 to 440b59b Compare December 4, 2024 20:10
@mtughan mtughan merged commit adce718 into jenkinsci:main Dec 4, 2024
17 checks passed
@mtughan mtughan deleted the parameters-null-check branch December 4, 2024 20:21
@mtughan mtughan added the bugfix label Dec 4, 2024
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not do this.

Copy link
Contributor Author

@mtughan mtughan Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only meant to be temporary until jenkinsci/jenkins#10026 is merged, as per the JEP-200 blog post:

  • If the class(es) are defined in a third-party library bundled in your plugin, create a resource file META-INF/hudson.remoting.ClassFilter listing them. (example)
    • You may also do this for Java or Jenkins core library classes, as a hotfix until your core baseline includes the whitelist entry proposed above.

this.builderId = builderId;
this.scriptId = scriptId;
this.parameters = new ArrayList<>(parameters);
this.parameters = parameters == null ? List.of() : List.copyOf(parameters);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not do this. Rather create a new ArrayList for the internal field used in the serial form.

@@ -175,7 +180,7 @@ public Parameter[] getParameters() {

@NonNull
public List<Parameter> getParametersList() {
return Collections.unmodifiableList(parameters);
return parameters;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whether you should revert this or not would depend on whether or not you want callers to modify the list. Probably you do not, so this should be reverted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently safe as returning an unmodifiable view of an immutable list is a no-op.

Copy link
Contributor Author

@mtughan mtughan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's finish the discussion in jenkinsci/jenkins#10026 first before deciding the next steps here.

@@ -175,7 +180,7 @@ public Parameter[] getParameters() {

@NonNull
public List<Parameter> getParametersList() {
return Collections.unmodifiableList(parameters);
return parameters;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently safe as returning an unmodifiable view of an immutable list is a no-op.

Copy link
Contributor Author

@mtughan mtughan Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only meant to be temporary until jenkinsci/jenkins#10026 is merged, as per the JEP-200 blog post:

  • If the class(es) are defined in a third-party library bundled in your plugin, create a resource file META-INF/hudson.remoting.ClassFilter listing them. (example)
    • You may also do this for Java or Jenkins core library classes, as a hotfix until your core baseline includes the whitelist entry proposed above.

@jglick
Copy link
Member

jglick commented Dec 9, 2024

If the class(es) are defined in a third-party library bundled in your plugin…

is meant for plugins historically using some unusual class in XStream serialized forms, where that usage cannot readily be replaced with a simple form without significant compatibility code.

@mtughan
Copy link
Contributor Author

mtughan commented Dec 9, 2024

If the class(es) are defined in a third-party library bundled in your plugin…

is meant for plugins historically using some unusual class in XStream serialized forms, where that usage cannot readily be replaced with a simple form without significant compatibility code.

I was more pointing out the second part,

You may also do this for Java or Jenkins core library classes, as a hotfix until your core baseline includes the whitelist entry proposed above.

I created this file as a hotfix until the core includes support for this class.

@jglick
Copy link
Member

jglick commented Dec 9, 2024

I think you misunderstood. That was for the period of time when JEP-200 first shipped, and for existing plugin code.

@mtughan
Copy link
Contributor Author

mtughan commented Dec 10, 2024

I think you misunderstood. That was for the period of time when JEP-200 first shipped, and for existing plugin code.

Ah, gotcha. Thanks for the clarification.

@mtughan
Copy link
Contributor Author

mtughan commented Dec 10, 2024

@jglick, all your comments should be addressed in #135 now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants