Re: Understanding Jenkins Core Vulnerabilities in plugin s
Thanks for the info, very helpful. And as to your question, no. Must be a coincidence. This has come up on our end by simply reviewing the current status. Cheers. On Tuesday, February 22, 2022 at 10:11:37 AM UTC+2 db...@cloudbees.com wrote: > On Tue, Feb 22, 2022 at 7:25 AM Niv Keidan wrote: > >> I am running Jenkins 2.319.3 and using a plugin that has 2.277.4 defined >> as in its pom.xml. >> Am I exposed to the vulnerabilities in 2.277.4? >> > > No, this only defines the minimum compatible version. The same applies to > dependencies to other plugins. Only bundled libraries (hpi/jpi files are > just zip, open it and look inside) matter. That's why Jenkins doesn't show > security warnings to admins when you update the affected component. > > Tell your security scanner vendor to improve their product to not believe > everything the pom.xml says. > > I'm curious, did a big vendor release some nonsense? This is the third > time this has come up in ~4 days. > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a8fb4abc-1c61-4d28-a619-643f47e4f78dn%40googlegroups.com.
Understanding Jenkins Core Vulnerabilities in plugin s
Hello everyone. I am trying to understand the impact of Jenkins core security vulnerabilities on plugin usage. Lets do this with an example: I am running Jenkins 2.319.3 and using a plugin that has 2.277.4 defined as in its pom.xml. Am I exposed to the vulnerabilities in 2.277.4? Does it depend on where the vulnerability actually is in the code? Is some core code compiled along with the plugin? If someone could explain a bit on how compiling and running plugins works - it would be very helpful. Thank you very much. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c95a1ae2-63b1-4dcf-b779-e040849a409fn%40googlegroups.com.
Re: assistance with running test locally
cleaning did the trick, thank you On Friday, January 28, 2022 at 8:20:15 PM UTC Jesse Glick wrote: > On Fri, Jan 28, 2022 at 2:16 PM Niv Keidan wrote: > >> command: mvn -Dtest=hudson.model.NodeTest test > > > The exact same command works for me. Are you using JDK 8? Did you try `mvn > -Pquick-build clean install` to start? Did you check behavior in `master`? > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/226a79b7-fcf8-45b0-906a-2b2739e2d60fn%40googlegroups.com.
Re: assistance with running test locally
command: mvn -Dtest=hudson.model.NodeTest test all tests fail with same stack trace using local branch for this PR https://github.com/jenkinsci/jenkins/pull/6193 Just trying to get some tests running before writing a new one On Friday, January 28, 2022 at 7:15:10 PM UTC timja...@gmail.com wrote: > Could you add more context? > > Which test? > Which repo? > > How are you trying to run it? > > On Fri, 28 Jan 2022 at 19:09, Niv Keidan wrote: > >> Hey guys, >> Working on a PR I am trying to run a single test locally and hitting this >> stack trace: >> >> org.jvnet.hudson.reactor.ReactorException: >> java.lang.IllegalArgumentException: Unable to inject class >> hudson.model.UserIdMapper at >> org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:291) at >> jenkins.InitReactorRunner.run(InitReactorRunner.java:49) at >> jenkins.model.Jenkins.executeReactor(Jenkins.java:1190) at >> jenkins.model.Jenkins.(Jenkins.java:981) at >> hudson.model.Hudson.(Hudson.java:86) at >> org.jvnet.hudson.test.JenkinsRule.newHudson(JenkinsRule.java:688) at >> org.jvnet.hudson.test.JenkinsRule.before(JenkinsRule.java:404) at >> org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:595) at >> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) >> >> at >> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) >> >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at >> java.base/java.lang.Thread.run(Thread.java:829) Caused by: >> java.lang.IllegalArgumentException: Unable to inject class >> hudson.model.UserIdMapper at >> hudson.init.TaskMethodFinder.lookUp(TaskMethodFinder.java:130) at >> hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110) at >> hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:185) at >> org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:305) at >> jenkins.model.Jenkins$5.runTask(Jenkins.java:1156) at >> org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:222) at >> org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:121) at >> jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68) >> >> at >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >> at >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >> ... 1 more >> >> any idea? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkinsci-de...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/fd3e9129-aeb0-4783-bd39-792c3f5b920cn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/fd3e9129-aeb0-4783-bd39-792c3f5b920cn%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6d3fce51-1046-4a2e-b599-0cd34df22b45n%40googlegroups.com.
assistance with running test locally
Hey guys, Working on a PR I am trying to run a single test locally and hitting this stack trace: org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalArgumentException: Unable to inject class hudson.model.UserIdMapper at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:291) at jenkins.InitReactorRunner.run(InitReactorRunner.java:49) at jenkins.model.Jenkins.executeReactor(Jenkins.java:1190) at jenkins.model.Jenkins.(Jenkins.java:981) at hudson.model.Hudson.(Hudson.java:86) at org.jvnet.hudson.test.JenkinsRule.newHudson(JenkinsRule.java:688) at org.jvnet.hudson.test.JenkinsRule.before(JenkinsRule.java:404) at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:595) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.IllegalArgumentException: Unable to inject class hudson.model.UserIdMapper at hudson.init.TaskMethodFinder.lookUp(TaskMethodFinder.java:130) at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110) at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:185) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:305) at jenkins.model.Jenkins$5.runTask(Jenkins.java:1156) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:222) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:121) at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ... 1 more any idea? -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fd3e9129-aeb0-4783-bd39-792c3f5b920cn%40googlegroups.com.
Re: not sure where to report issues with 2.319.2
My first PR to this project to fix this issue! :-) https://github.com/jenkinsci/jenkins/pull/6193 On Wednesday, January 19, 2022 at 4:38:45 PM UTC Niv Keidan wrote: > https://issues.jenkins.io/browse/JENKINS-67635 > > On Wednesday, January 19, 2022 at 4:05:52 PM UTC Niv Keidan wrote: > >> Thanks Mark, >> I will open a ticket, but just so you guys know this IS an issue! >> >> A simple pipeline with "||" targeting *cloud* labels behaves differently >> on 2.319.2 than 2.319.1 >> >> I've tested this with two different plugins: EC2 plugin and Anka-Build. >> >> So, for example, using "label1 || label2" will produce the following >> behavior in the plugins: >> >> *EC2 Plugin:* >> EC2 start spinning label1 instances constantly, with no stopping seen in >> the horizon (I aborted the job after seeing 6 instances spin up) >> label2 is never used. >> In 2.319.1 one instance of label1 is spun up and one instance of label2 >> is spun up until one of them connects. no more. >> >> *Anka Build Plugin:* >> Pretty similar thing happens. Anka VMs are being spun up constantly. >> At some point, one of them is actually able to pick up an executor and >> the job moves on fine, but a single request can spin up even 4 VMs >> sometimes. >> In 2.319.1, a single VM would spin up if possible. If not, the second >> label would try to spin up >> >> I am working on the ticket as we speak but I thought you guys would like >> to know. >> On Wednesday, January 19, 2022 at 1:27:30 PM UTC Mark Waite wrote: >> >>> On Wednesday, January 19, 2022 at 5:59:46 AM UTC-7 Niv Keidan wrote: >>> >>>> Hello, >>>> >>>> I am seeing an issue related to nodes not picking up jobs when pipeline >>>> labels include "||". >>>> I believe this is related to >>>> https://issues.jenkins.io/browse/JENKINS-67099. >>>> >>>> Where should I report this? Is this the right place? >>>> >>>> >>> Best to report an issue on https://issues.jenkins.io . The report >>> needs to provide enough details so that others can duplicate the problem. >>> See https://www.jenkins.io/participate/report-issue for the types of >>> information needed. >>> >>> I have many jobs that use labels with '||' and have not noticed failures >>> with 2.319.2 and most recent plugins. Be sure you provide enough details >>> to show the issue to others. >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8eb70675-981b-41fa-b8b0-52ecd07c748fn%40googlegroups.com.
Re: not sure where to report issues with 2.319.2
https://issues.jenkins.io/browse/JENKINS-67635 On Wednesday, January 19, 2022 at 4:05:52 PM UTC Niv Keidan wrote: > Thanks Mark, > I will open a ticket, but just so you guys know this IS an issue! > > A simple pipeline with "||" targeting *cloud* labels behaves differently > on 2.319.2 than 2.319.1 > > I've tested this with two different plugins: EC2 plugin and Anka-Build. > > So, for example, using "label1 || label2" will produce the following > behavior in the plugins: > > *EC2 Plugin:* > EC2 start spinning label1 instances constantly, with no stopping seen in > the horizon (I aborted the job after seeing 6 instances spin up) > label2 is never used. > In 2.319.1 one instance of label1 is spun up and one instance of label2 is > spun up until one of them connects. no more. > > *Anka Build Plugin:* > Pretty similar thing happens. Anka VMs are being spun up constantly. > At some point, one of them is actually able to pick up an executor and the > job moves on fine, but a single request can spin up even 4 VMs sometimes. > In 2.319.1, a single VM would spin up if possible. If not, the second > label would try to spin up > > I am working on the ticket as we speak but I thought you guys would like > to know. > On Wednesday, January 19, 2022 at 1:27:30 PM UTC Mark Waite wrote: > >> On Wednesday, January 19, 2022 at 5:59:46 AM UTC-7 Niv Keidan wrote: >> >>> Hello, >>> >>> I am seeing an issue related to nodes not picking up jobs when pipeline >>> labels include "||". >>> I believe this is related to >>> https://issues.jenkins.io/browse/JENKINS-67099. >>> >>> Where should I report this? Is this the right place? >>> >>> >> Best to report an issue on https://issues.jenkins.io . The report >> needs to provide enough details so that others can duplicate the problem. >> See https://www.jenkins.io/participate/report-issue for the types of >> information needed. >> >> I have many jobs that use labels with '||' and have not noticed failures >> with 2.319.2 and most recent plugins. Be sure you provide enough details >> to show the issue to others. >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/da421241-d15d-4ff8-8318-0220403e7ea1n%40googlegroups.com.
Re: not sure where to report issues with 2.319.2
Thanks Mark, I will open a ticket, but just so you guys know this IS an issue! A simple pipeline with "||" targeting *cloud* labels behaves differently on 2.319.2 than 2.319.1 I've tested this with two different plugins: EC2 plugin and Anka-Build. So, for example, using "label1 || label2" will produce the following behavior in the plugins: *EC2 Plugin:* EC2 start spinning label1 instances constantly, with no stopping seen in the horizon (I aborted the job after seeing 6 instances spin up) label2 is never used. In 2.319.1 one instance of label1 is spun up and one instance of label2 is spun up until one of them connects. no more. *Anka Build Plugin:* Pretty similar thing happens. Anka VMs are being spun up constantly. At some point, one of them is actually able to pick up an executor and the job moves on fine, but a single request can spin up even 4 VMs sometimes. In 2.319.1, a single VM would spin up if possible. If not, the second label would try to spin up I am working on the ticket as we speak but I thought you guys would like to know. On Wednesday, January 19, 2022 at 1:27:30 PM UTC Mark Waite wrote: > On Wednesday, January 19, 2022 at 5:59:46 AM UTC-7 Niv Keidan wrote: > >> Hello, >> >> I am seeing an issue related to nodes not picking up jobs when pipeline >> labels include "||". >> I believe this is related to >> https://issues.jenkins.io/browse/JENKINS-67099. >> >> Where should I report this? Is this the right place? >> >> > Best to report an issue on https://issues.jenkins.io . The report needs > to provide enough details so that others can duplicate the problem. See > https://www.jenkins.io/participate/report-issue for the types of > information needed. > > I have many jobs that use labels with '||' and have not noticed failures > with 2.319.2 and most recent plugins. Be sure you provide enough details > to show the issue to others. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/cca5521a-3d34-44f6-bd3e-946626198d85n%40googlegroups.com.
not sure where to report issues with 2.319.2
Hello, I am seeing an issue related to nodes not picking up jobs when pipeline labels include "||". I believe this is related to https://issues.jenkins.io/browse/JENKINS-67099. Where should I report this? Is this the right place? Thank you! -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ddaf690b-cbd0-4744-a731-4d32df5a8ffdn%40googlegroups.com.
programmatic links to most recent LTS RC war
Is there a link that always redirects to the most recent LTS RC ? I'm seeing the last RCs being made available from https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/jenkins-war/ and I know in the past we used http://mirrors.jenkins-ci.org/war-stable-rc/latest/ We use this to automate plugin testing against future releases, to be prepared in case things break... Thanks in advance -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e70bbd2d-41a8-4360-a144-e1a36775de14n%40googlegroups.com.
Re: Custom Persistence For Plugin
Thanks for the tips. Just for a follow up if any one ever reads this, I have followed the advice as recommended by Jesse. I made the objects I referred to above transient and we are now handling their load/save by ourselves. We are using XmlFile to do that. Thanks everyone. On Wednesday, March 25, 2020 at 5:41:57 AM UTC+2, Jesse Glick wrote: > > On Tue, Mar 24, 2020 at 1:21 PM Niv Keidan > wrote: > > So first, we don't want all this redundant data to be saved (just flood > our cloud with transients is a valid solution...?? ) > > `transient` makes sense for most cases. > > > all the data that we DO want saved, when scaled up, can increase > config.xml size quite massively > > So this is some sort of cached metadata, rather than actual > configuration? You can store it elsewhere in `Jenkins.rootDir` however > you like. If you want to use the Jenkins style of persistence, you can > use `XmlFile`. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/30046282-4792-49a8-a912-2f874ac534fc%40googlegroups.com.
Re: Custom Persistence For Plugin
Hey, thanks for replying. Ok, so our plugin implements a cloud (that is saved in config.xml when configured by the user, which is amazing) This cloud object, after being instantiated (either loaded on startup or changed in configuration), creates all sorts of objects (duh), and those are being saved along with it on every save() execution. So first, we don't want all this redundant data to be saved (just flood our cloud with transients is a valid solution...?? ) And secondly, all the data that we DO want saved, when scaled up, can increase config.xml size quite massively, and that does not sound nice to us at all. Any thoughts? On Tue, Mar 24, 2020 at 6:54 PM 'Gavin Mogan' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > Why are you not pleased with it? What is it doing? What isn't it doing? > > On Tue., Mar. 24, 2020, 9:50 a.m. Niv Keidan, > wrote: > >> Hello everyone. >> >> We have a plugin that extends a cloud (among other classes) and we wish >> for some cloud related data to be persistent between restarts. >> This data changes very often and we need to make sure we save it every >> time it changes. >> >> At the moment, we are using Jenkins.getInstance().save() but we are not >> pleased with this solution. >> >> Are there alternatives? >> Or, can we customize the way save() behaves? >> >> Appreciate any help/advice. >> >> Thanks, >> Niv (Veertu.com) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkinsci-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/657e2db6-37a5-473d-ae82-34af7b6b0b22%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/657e2db6-37a5-473d-ae82-34af7b6b0b22%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/0G7n_sk1ax4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusP3OBZG9a37ESjuxMNj%3DqxUjKd1pvgixnRzKos%3DdSHHw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusP3OBZG9a37ESjuxMNj%3DqxUjKd1pvgixnRzKos%3DdSHHw%40mail.gmail.com?utm_medium=email_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJuE1H54N%3Df3GAo92dw%3D4LWac2SXQKLyvzpdqRRGgpsvT%2BDRug%40mail.gmail.com.
Custom Persistence For Plugin
Hello everyone. We have a plugin that extends a cloud (among other classes) and we wish for some cloud related data to be persistent between restarts. This data changes very often and we need to make sure we save it every time it changes. At the moment, we are using Jenkins.getInstance().save() but we are not pleased with this solution. Are there alternatives? Or, can we customize the way save() behaves? Appreciate any help/advice. Thanks, Niv (Veertu.com) -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/657e2db6-37a5-473d-ae82-34af7b6b0b22%40googlegroups.com.
