I use XmlSlurper.parseText() to read some information from pom.xml file, but in the sandbox I do not even have the option to approve it or not.

Probably the same issues as JENKINS-35140.

I have the same use case as Flavio. Can you recommend a sandbox friendly workaround to parse the groupId, artifactId, and version from my pom.xml that does not require approvals?

what about https://jenkins.io/doc/pipeline/steps/pipeline-utility-steps/#readmavenpom-read-a-maven-project-file

jglick could you please explain us why you decided to close this as "won't fix"? Is there a broader decision regarding Groovy Language compatibility?

Yes, things like XmlSlurper should not be used. You may use dedicated Pipeline steps, or (preferably) external tools run inside node.

Blocking IO should use steps or an external tool (reading a file from the workspace, http/s connection, etc.)

But if I already have the XML data as text I should be able to parse it without jumping through hoops. For example my build extracts build numbers from multiple sources. I use steps to parse my pom.xml from a workspace and do a http request to download maven-metadata.xml from my Nexus server. But after the download I still need to parse that maven-metatadata.xml to extract the deployed version numbers. Today I have to call a Global Library helper to parse that file due to the lack of XMLSlurper being white listed.

I would note that the JsonSlurper & JsonOutput are already in the whitelist (https://github.com/jenkinsci/script-security-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/generic-whitelist).

XmlSlurper is too problematic and will not be supported.

Can you explain why. Currently I'm whitelisting it myself but if there security implications I'm unaware of I would like to understand.

It is sensitive to thread context class loader issues, which can cause mysterious errors from apparently unrelated plugins. Certain methods are also inappropriate to whitelist.