During JEP-200 testing before the release I was unable to test Artifactory plugin due to its old codebase and dependencies. Clearly I need to finish the effort

https://github.com/jenkinsci/artifactory-plugin/pull/30 should close the issue with Remoting serialization.

So far I do not see obvious issues with serialization of 3rd-party classes in XStream, but the codebase it too big to say for sure. Almost all build actions persist build references, so the plugin needs a cleanup anyway.

For clarification, this task pops up first in google when searching for problem.

Workaround is -Djenkins.security.ClassFilterImpl.SUPPRESS_WHITELIST=true

Yes, in that mode violations will only be logged but execution will proceed. Use at your own risk. This flag is best used to collect a set of entries which should then be added to the hudson.remoting.ClassFilter system property.

I have pinged JFrog about the issue

Is there a workaround for generic artifactory pushes for Jenkins Pipeline As a Code? I'm seeing this issue while uploading my build artifacts via Jenkinsfile. It doesn't even show up in in-script approval.

java.lang.SecurityException: Rejected: org.jfrog.build.api.Artifact
at hudson.remoting.ClassFilter.check(ClassFilter.java:75)
at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:129)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:433)
at java.util.ArrayList.readObject(ArrayList.java:797)
at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:433)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:277)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:909)
at hudson.FilePath.act(FilePath.java:998)
at hudson.FilePath.act(FilePath.java:987)
at org.jfrog.hudson.pipeline.executors.GenericUploadExecutor.execution(GenericUploadExecutor.java:52)
at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:65)
at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:46)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:274)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE

It won't, JEP-200 behaves differently. See the offered patch, which is the best best available workaround now

Is there a workaround for generic artifactory pushes for Jenkins Pipeline As a Code?

Uninstall the plugin and

sh 'mvn deploy'

jglick What do you mean uninstall plugin and "mvn deploy"? Build artifactory plugin from source?

jglick yeah we aren't doing maven builds. We use the artifactory plugin to upload and download array of assets to jobs... ranging from rpm builds to simple text files. So not sure mvn deploy will work for non-Maven repositories.

cdenneen well, I was using mvn deploy as an example only. Presumably there is some documented REST API for uploading and downloading artifacts in general repository formats, which you could invoke from curl or the like, given suitable withCredentials.

cdenneen if you are a JFrog customer, submit a ticket to them. I have submitted my one, but more tickets would raise the priority I'd guess

oleg_nenashev We are but a PRO customer which doesn't have "support". So best I could do is open issue on their public board. Hopefully your ticket will get some traction.

Until then does the snapshot of the plugin work or the sysconfig changes work for now as work around enough?

cdenneen the Snapshot will work in some case, e.g. Maven publishing.
I cannot guarantee stability of other case (most likely "no"), but I am happy to update the pull request according to the feedback.

The plugin has no tests, and JEP-200 maintainers have no time to setup a test environment for every case

oleg_nenashev looks like 2.104 might have added the whitelists?

Any idea what could be causing this?

java.lang.SecurityException: Rejected: org.jfrog.build.api.Dependency

> looks like 2.104 might have added the whitelists?

It has added only few basic types which impact the plugin, but not the 3rd-party libraries.
So the patch on the core's side is not going to resolve the issue

Is this JIRA resolved? I'm facing the same issue.

I'm trying to use the command -Djenkins.security.ClassFilterImpl.SUPPRESS_WHITELIST=true but don't know how to use it. It would be helpful if you provide the resolution or workaround step in little more detail.

The fix has been finally released in 2.15.0