findsecbugs in spotbugs

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

findsecbugs in spotbugs

Jeff Thompson
Jenkins developers,

I've been working on introducing findsecbugs into the Jenkins developer
ecosystem. findsecbugs is a plugin for spotbugs (formerly findbugs) that
adds analysis for a significant collection of bug rules that could
potentially impact security. More information is at
https://find-sec-bugs.github.io/

I've got PRs about ready for merge to introduce findsecbugs into Jenkins
( https://github.com/jenkinsci/jenkins/pull/4381 ) and Remoting (
https://github.com/jenkinsci/remoting/pull/361 ).

The problem with introducing a tool like this in any legacy software is
that it finds things that could have been better implemented or are
outdated but are not real issues. Turning it on means going through the
all the findings, analyzing them, and then suppressing them (hopefully
individually) or fixing them. I've done that in my two PRs.

I've also gone through this with a sampling of 7 plugins. Only one of
them didn't detect any findings, but they didn't necessarily have any
real security issues. I intend to push PRs for these plugins I've tried
in the coming days.

I believe there is a lot of value in having this tool detect new,
potential issues as we move forward with changes and new code. I've been
glad in the past at how spotbugs and other tools help catch things
before PRs are merged.

I want to get findsecbugs turned on in the parent plugin pom.
@StefanSpieker also has a PR to turn it on in the parent Jenkins pom.

I'm not sure whether we need to be more cautious about turning
findsecbugs on in the parent poms. Do we need to make it opt-in? How do
we encourage people to opt-in? Or, does that just become something
everyone has to do to move forward to latest poms? At a minimum I think
we should use @StefanSpieker's PR to turn it on in the Jenkins parent pom.

Jeff Thompson

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/abf5a687-e4a1-6c44-6c2a-fab071ef84cd%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Raihaan Shouhell
Hey Jeff,

I think it is ok to introduce it. Sounds like it would add value.
There should be a switch to at least disable failing the build because of findsecbugs.

Despite the potential problems with introducing it, I am +1 on it since it will definitely help the development of new plugins.

Like you said spotbugs has actually helped find a ton of bugs, I even find myself getting annoyed when the relevant annotation was missing that could potentially avoid a bug.
If this tool can help us avoid security issues the same way spotbugs helps with bugs that would be awesome.

Cheers,
Raihaan

On Wednesday, 11 December 2019 04:27:16 UTC+8, Jeff Thompson wrote:
Jenkins developers,

I've been working on introducing findsecbugs into the Jenkins developer
ecosystem. findsecbugs is a plugin for spotbugs (formerly findbugs) that
adds analysis for a significant collection of bug rules that could
potentially impact security. More information is at
<a href="https://find-sec-bugs.github.io/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ffind-sec-bugs.github.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEXQhO1--9qW0JU01grK5-JMPj8yA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ffind-sec-bugs.github.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEXQhO1--9qW0JU01grK5-JMPj8yA&#39;;return true;">https://find-sec-bugs.github.io/

I've got PRs about ready for merge to introduce findsecbugs into Jenkins
( <a href="https://github.com/jenkinsci/jenkins/pull/4381" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4381\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1QGfeLH4Dz6xgbOWVa1Z8DEeJ-g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4381\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1QGfeLH4Dz6xgbOWVa1Z8DEeJ-g&#39;;return true;">https://github.com/jenkinsci/jenkins/pull/4381 ) and Remoting (
<a href="https://github.com/jenkinsci/remoting/pull/361" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F361\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE37WwpHECTjjjVlOI73W9d0XzirQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F361\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE37WwpHECTjjjVlOI73W9d0XzirQ&#39;;return true;">https://github.com/jenkinsci/remoting/pull/361 ).

The problem with introducing a tool like this in any legacy software is
that it finds things that could have been better implemented or are
outdated but are not real issues. Turning it on means going through the
all the findings, analyzing them, and then suppressing them (hopefully
individually) or fixing them. I've done that in my two PRs.

I've also gone through this with a sampling of 7 plugins. Only one of
them didn't detect any findings, but they didn't necessarily have any
real security issues. I intend to push PRs for these plugins I've tried
in the coming days.

I believe there is a lot of value in having this tool detect new,
potential issues as we move forward with changes and new code. I've been
glad in the past at how spotbugs and other tools help catch things
before PRs are merged.

I want to get findsecbugs turned on in the parent plugin pom.
@StefanSpieker also has a PR to turn it on in the parent Jenkins pom.

I'm not sure whether we need to be more cautious about turning
findsecbugs on in the parent poms. Do we need to make it opt-in? How do
we encourage people to opt-in? Or, does that just become something
everyone has to do to move forward to latest poms? At a minimum I think
we should use @StefanSpieker's PR to turn it on in the Jenkins parent pom.

Jeff Thompson

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/551b065c-8a6c-47d8-8377-b3d186db363d%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

jn...@cloudbees.com
I had a quick peek at the 2 PRs and my main concern is that this found no security issues and forced annotations on a lot of places, that is it found no issues according to the PRs.

Whilst it could prevent issues being introduced in the future I am concerned it will cause 99% `@SuppressFBWarning` annoyance and not find the security issue.
The suppressions are also overly broad - for example https://github.com/jenkinsci/jenkins/pull/4381/files#diff-6b2c22336dd63b20019b8558c7e9a13fR599-R601  is completely incorrect.  This code can not make assumptions about the callers - only the caller of that method can make it and as such the Annotation needs to be on those methods not the utility method.

in other words I think if this just causes pain by having to add suppress warnings then I think it would be a bad thing.  I would be happy to see it catch the first real issue - but if that does not happen in a long time I think we should be prepared to back this out.  

my 2c.

On Wednesday, December 11, 2019 at 12:44:36 AM UTC, Raihaan Shouhell wrote:
Hey Jeff,

I think it is ok to introduce it. Sounds like it would add value.
There should be a switch to at least disable failing the build because of findsecbugs.

Despite the potential problems with introducing it, I am +1 on it since it will definitely help the development of new plugins.

Like you said spotbugs has actually helped find a ton of bugs, I even find myself getting annoyed when the relevant annotation was missing that could potentially avoid a bug.
If this tool can help us avoid security issues the same way spotbugs helps with bugs that would be awesome.

Cheers,
Raihaan

On Wednesday, 11 December 2019 04:27:16 UTC+8, Jeff Thompson wrote:
Jenkins developers,

I've been working on introducing findsecbugs into the Jenkins developer
ecosystem. findsecbugs is a plugin for spotbugs (formerly findbugs) that
adds analysis for a significant collection of bug rules that could
potentially impact security. More information is at
<a href="https://find-sec-bugs.github.io/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ffind-sec-bugs.github.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEXQhO1--9qW0JU01grK5-JMPj8yA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Ffind-sec-bugs.github.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEXQhO1--9qW0JU01grK5-JMPj8yA&#39;;return true;">https://find-sec-bugs.github.io/

I've got PRs about ready for merge to introduce findsecbugs into Jenkins
( <a href="https://github.com/jenkinsci/jenkins/pull/4381" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4381\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1QGfeLH4Dz6xgbOWVa1Z8DEeJ-g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4381\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1QGfeLH4Dz6xgbOWVa1Z8DEeJ-g&#39;;return true;">https://github.com/jenkinsci/jenkins/pull/4381 ) and Remoting (
<a href="https://github.com/jenkinsci/remoting/pull/361" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F361\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE37WwpHECTjjjVlOI73W9d0XzirQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F361\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE37WwpHECTjjjVlOI73W9d0XzirQ&#39;;return true;">https://github.com/jenkinsci/remoting/pull/361 ).

The problem with introducing a tool like this in any legacy software is
that it finds things that could have been better implemented or are
outdated but are not real issues. Turning it on means going through the
all the findings, analyzing them, and then suppressing them (hopefully
individually) or fixing them. I've done that in my two PRs.

I've also gone through this with a sampling of 7 plugins. Only one of
them didn't detect any findings, but they didn't necessarily have any
real security issues. I intend to push PRs for these plugins I've tried
in the coming days.

I believe there is a lot of value in having this tool detect new,
potential issues as we move forward with changes and new code. I've been
glad in the past at how spotbugs and other tools help catch things
before PRs are merged.

I want to get findsecbugs turned on in the parent plugin pom.
@StefanSpieker also has a PR to turn it on in the parent Jenkins pom.

I'm not sure whether we need to be more cautious about turning
findsecbugs on in the parent poms. Do we need to make it opt-in? How do
we encourage people to opt-in? Or, does that just become something
everyone has to do to move forward to latest poms? At a minimum I think
we should use @StefanSpieker's PR to turn it on in the Jenkins parent pom.

Jeff Thompson

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b1fde6e8-38df-4c4c-9da5-fbf616c2c099%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Jeff Thompson

James,

You make valid points. Many of them, though, represent the nature of spotbugs, how it works, and particularly the difficulties of adding anything like it to legacy code. The problem just becomes perpetual -- the only good time to ever add these kinds of checks is in the past, there is a hurdle to adding them and dealing with them at any current or future point, which tends to result in overly broad suppressions, and so it's easy to just keep putting it off. Once added, these checks provide value: they make it harder to introduce new problems (of the types checked) and they point out areas of technical debt that can be improved.

In rough terms, I see the following approaches:

1) Make no changes. Continuing as we are just keeps us ignorant of the potential issues. With regular issues this may just mean there is a defect that needs to be fixed. With findsecbugs, it may be an exploitable security bug. Our ignorance doesn't protect us.

2) Something along the lines of my proposals: Enable it at the current spotbugs level, examine the individual findings, and suppress or act individually. As you note, this does lead to a lot of individual @SuppressFBWarning lines.

3) Enable it but don't suppress (nearly) anything. This requires (almost) all findings to be "corrected" before it's enabled for new development. Since we would be making sure not to suppress unless absolutely necessary we would need to first fix bad coding practice that doesn't result in usage issues. With legacy code, particularly on the scale of Jenkins, this practically becomes approach #1 because the barrier to ever doing it becomes too high.

4) Enable it but suppress via the exclude file rather than embedded @SuppressFBWarning lines. This tends to lead people to suppress by bug or category rather than examining the individual findings. If used more precisely, it disconnects the finding from the code, making it more difficult to eventually correct the technical debt.


My experiments with findsecbugs have found some areas of real concern. There's one I can readily share publicly at this time to illustrate. As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 / CVE-2019-10320, which was fixed in the 2019-05-21 advisory. The scanner found it in the master branch, because we left part of the code in to facilitate migration. (It's essentially impossible to create new configurations with the problem.) The combination of the @Deprecated and @SuppressFBWarning annotations highlight that it should be fully removed some day. If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.

My experience with spotbugs is that it can be a hassle at times, but it tends to encourage cleaner code and sometimes it finds real concerns.

I don't know how we could ever get around to enabling new rules except with something along the lines of my proposal, #2. I hope we can proceed with it, even if imperfectly.

Jeff

On 12/11/19 5:28 AM, James Nord wrote:
I had a quick peek at the 2 PRs and my main concern is that this found no security issues and forced annotations on a lot of places, that is it found no issues according to the PRs.

Whilst it could prevent issues being introduced in the future I am concerned it will cause 99% `@SuppressFBWarning` annoyance and not find the security issue.
The suppressions are also overly broad - for example https://github.com/jenkinsci/jenkins/pull/4381/files#diff-6b2c22336dd63b20019b8558c7e9a13fR599-R601  is completely incorrect.  This code can not make assumptions about the callers - only the caller of that method can make it and as such the Annotation needs to be on those methods not the utility method.

in other words I think if this just causes pain by having to add suppress warnings then I think it would be a bad thing.  I would be happy to see it catch the first real issue - but if that does not happen in a long time I think we should be prepared to back this out.  

my 2c.

On Wednesday, December 11, 2019 at 12:44:36 AM UTC, Raihaan Shouhell wrote:
Hey Jeff,

I think it is ok to introduce it. Sounds like it would add value.
There should be a switch to at least disable failing the build because of findsecbugs.

Despite the potential problems with introducing it, I am +1 on it since it will definitely help the development of new plugins.

Like you said spotbugs has actually helped find a ton of bugs, I even find myself getting annoyed when the relevant annotation was missing that could potentially avoid a bug.
If this tool can help us avoid security issues the same way spotbugs helps with bugs that would be awesome.

Cheers,
Raihaan

On Wednesday, 11 December 2019 04:27:16 UTC+8, Jeff Thompson wrote:
Jenkins developers,

I've been working on introducing findsecbugs into the Jenkins developer
ecosystem. findsecbugs is a plugin for spotbugs (formerly findbugs) that
adds analysis for a significant collection of bug rules that could
potentially impact security. More information is at
<a href="https://find-sec-bugs.github.io/" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Ffind-sec-bugs.github.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEXQhO1--9qW0JU01grK5-JMPj8yA';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Ffind-sec-bugs.github.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEXQhO1--9qW0JU01grK5-JMPj8yA';return true;" moz-do-not-send="true">https://find-sec-bugs.github.io/

I've got PRs about ready for merge to introduce findsecbugs into Jenkins
( <a href="https://github.com/jenkinsci/jenkins/pull/4381" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4381\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1QGfeLH4Dz6xgbOWVa1Z8DEeJ-g';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F4381\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE1QGfeLH4Dz6xgbOWVa1Z8DEeJ-g';return true;" moz-do-not-send="true">https://github.com/jenkinsci/jenkins/pull/4381 ) and Remoting (
<a href="https://github.com/jenkinsci/remoting/pull/361" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F361\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE37WwpHECTjjjVlOI73W9d0XzirQ';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F361\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE37WwpHECTjjjVlOI73W9d0XzirQ';return true;" moz-do-not-send="true">https://github.com/jenkinsci/remoting/pull/361 ).

The problem with introducing a tool like this in any legacy software is
that it finds things that could have been better implemented or are
outdated but are not real issues. Turning it on means going through the
all the findings, analyzing them, and then suppressing them (hopefully
individually) or fixing them. I've done that in my two PRs.

I've also gone through this with a sampling of 7 plugins. Only one of
them didn't detect any findings, but they didn't necessarily have any
real security issues. I intend to push PRs for these plugins I've tried
in the coming days.

I believe there is a lot of value in having this tool detect new,
potential issues as we move forward with changes and new code. I've been
glad in the past at how spotbugs and other tools help catch things
before PRs are merged.

I want to get findsecbugs turned on in the parent plugin pom.
@StefanSpieker also has a PR to turn it on in the parent Jenkins pom.

I'm not sure whether we need to be more cautious about turning
findsecbugs on in the parent poms. Do we need to make it opt-in? How do
we encourage people to opt-in? Or, does that just become something
everyone has to do to move forward to latest poms? At a minimum I think
we should use @StefanSpieker's PR to turn it on in the Jenkins parent pom.

Jeff Thompson

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b1fde6e8-38df-4c4c-9da5-fbf616c2c099%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bc04ddfa-9a1b-3c61-221f-13f8661a65e8%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Jesse Glick-4
On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson <[hidden email]> wrote:
> As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 […]
> If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.

You are referring to

https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

I agree that the only maintainable usage mode is to examine individual
lines of code and either rewrite them or add `@SuppressFBWarning`. It
can be tedious, but it is compatible with code review and incremental
improvements.

One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Rz%2BciBh%3DtWXH-K_jYJU45fTsXPMEu7U6JOpJ%2B4e0ULw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Jeff Thompson

On 12/12/19 7:10 AM, Jesse Glick wrote:

On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson [hidden email] wrote:
As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 […]
If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.
You are referring to

https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

Yes, that's the one.

Findsecbugs is clearly biased to web applications, which makes it fairly applicable to Jenkins. Some things it reports on the agent side of Remoting would be important on a server. Remoting operates on both sides so it requires consideration as to how or where each piece runs. There are some findsecbugs rules (at least 1) that just aren't treated as a concern in Jenkins. As I've been analyzing findings I've thought it would be cool to have some Jenkins-specific rules for findsecbugs, spotbugs, or some other tool to catch some of those idiosyncratic things. But, there's enough value in the rules it does have to catch common things. We should move forward on these ones because they're useful and maybe someday we can introduce some Jenkins-specific checks somewhere.

One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

+10

This would be fantastic. Sometimes I remove a suppress annotation and see if it's still necessary -- often it isn't. Going through these analyses I found a number of cases where an existing annotation was no longer necessary. It would be great to have this capability, but I'm not motivated enough to contribute this to spotbugs.

Jeff

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f1e2acb5-f896-3048-eca1-bdc8cbf968d9%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

jn...@cloudbees.com


On Thursday, December 12, 2019 at 6:28:21 PM UTC, Jeff Thompson wrote:

On 12/12/19 7:10 AM, Jesse Glick wrote:

On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson <a href="javascript:" target="_blank" gdf-obfuscated-mailto="vw42kpGaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;"><jtho...@...> wrote:
As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 […]
If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.
You are referring to

<a href="https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fcredentials-plugin%2Fcommit%2F40d0b5cc53c265b601ffaa4469310fad390a80fb\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGJTALegmPrHC1QTsr-7pH97e_Jjw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fcredentials-plugin%2Fcommit%2F40d0b5cc53c265b601ffaa4469310fad390a80fb\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGJTALegmPrHC1QTsr-7pH97e_Jjw&#39;;return true;">https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

Yes, that's the one.

Findsecbugs is clearly biased to web applications, which makes it fairly applicable to Jenkins. Some things it reports on the agent side of Remoting would be important on a server. Remoting operates on both sides so it requires consideration as to how or where each piece runs. There are some findsecbugs rules (at least 1) that just aren't treated as a concern in Jenkins. As I've been analyzing findings I've thought it would be cool to have some Jenkins-specific rules for findsecbugs, spotbugs, or some other tool to catch some of those idiosyncratic things. But, there's enough value in the rules it does have to catch common things. We should move forward on these ones because they're useful and maybe someday we can introduce some Jenkins-specific checks somewhere.

One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

+10

This would be fantastic. Sometimes I remove a suppress annotation and see if it's still necessary -- often it isn't. Going through these analyses I found a number of cases where an existing annotation was no longer necessary. It would be great to have this capability, but I'm not motivated enough to contribute this to spotbugs.

Jeff


We now have the ability to actually put the suppressions at a finer level than just the method for many issues.  If we started to consiously do that it would be clearer when some things can be removed.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/54b09ff3-0494-4e30-8b32-b50cf144e654%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Ulli Hafner
If it helps to prevent some errors I think it would make sense to enable it for plugins as well (in the parent pom). Can the execution of this additional plugin be removed in a specific plugin pom afterwards? I’m not sure how maven handles it.

I enabled the checker in my plugins and needed to disable it for tests as there where too many false positives have been reported:

<Match>
  <Bug category="SECURITY"/>
  <Class name="~.*Test.*" />
</Match>

 Additionally, I deactivated the following rules that seem to produce too many false positives:

<Match>
  <Bug pattern="DESERIALIZATION_GADGET, FORMAT_STRING_MANIPULATION, PATH_TRAVERSAL_IN, WEAK_FILENAMEUTILS"/>
</Match>

Maybe it makes sense to gather feedback from some other plugins as well before changing the parent pom.

Am 13.12.2019 um 12:30 schrieb James Nord <[hidden email]>:



On Thursday, December 12, 2019 at 6:28:21 PM UTC, Jeff Thompson wrote:

On 12/12/19 7:10 AM, Jesse Glick wrote:

On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson <[hidden email]> wrote:
As I was analyzing one findsecbugs finding, I immediately recognized it as SECURITY-1322 […]
If someone had run findsecbugs a year ago it would have caught that as a real vulnerability.
You are referring to

https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

Yes, that's the one.

Findsecbugs is clearly biased to web applications, which makes it fairly applicable to Jenkins. Some things it reports on the agent side of Remoting would be important on a server. Remoting operates on both sides so it requires consideration as to how or where each piece runs. There are some findsecbugs rules (at least 1) that just aren't treated as a concern in Jenkins. As I've been analyzing findings I've thought it would be cool to have some Jenkins-specific rules for findsecbugs, spotbugs, or some other tool to catch some of those idiosyncratic things. But, there's enough value in the rules it does have to catch common things. We should move forward on these ones because they're useful and maybe someday we can introduce some Jenkins-specific checks somewhere.


One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

+10

This would be fantastic. Sometimes I remove a suppress annotation and see if it's still necessary -- often it isn't. Going through these analyses I found a number of cases where an existing annotation was no longer necessary. It would be great to have this capability, but I'm not motivated enough to contribute this to spotbugs.

Jeff


We now have the ability to actually put the suppressions at a finer level than just the method for many issues.  If we started to consiously do that it would be clearer when some things can be removed.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/54b09ff3-0494-4e30-8b32-b50cf144e654%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/73776A3C-E2B5-40AC-BBFC-36AF613EA635%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Jeff Thompson

Yes, my goal is to also enable findsecbugs in the plugin parent pom. I think it's well worth it, just as regular spotbugs provides valuable findings in a number of cases.

I've currently got PRs awaiting review and approval for jenkins and remoting. I've got one approval for remoting so I'll proceed to merge that in before long.

I've also prepared branches for about half a dozen plugins where I've added it into their local configuration. I have planned on pushing those soon.

My idea is to prove it out with a selected set of projects and then work to roll it out more widely. I'm not sure how we want to proceed with adding it into the plugin parent pom. I'd like to just make it a standard part, but I think we might need to make it opt-in, such as with a profile, at least for an introductory period.

Thanks for the response,

Jeff

On 12/19/19 6:41 AM, Ullrich Hafner wrote:
If it helps to prevent some errors I think it would make sense to enable it for plugins as well (in the parent pom). Can the execution of this additional plugin be removed in a specific plugin pom afterwards? I’m not sure how maven handles it.

I enabled the checker in my plugins and needed to disable it for tests as there where too many false positives have been reported:

<Match>
  <Bug category="SECURITY"/>
  <Class name="~.*Test.*" />
</Match>

 Additionally, I deactivated the following rules that seem to produce too many false positives:

<Match>
  <Bug pattern="DESERIALIZATION_GADGET, FORMAT_STRING_MANIPULATION, PATH_TRAVERSAL_IN, WEAK_FILENAMEUTILS"/>
</Match>

Maybe it makes sense to gather feedback from some other plugins as well before changing the parent pom.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/30893ff4-685f-f31a-632a-6b938b91a4b1%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Jeff Thompson

I'm circling back to this discussion here on the dev list. I've gotten findsecbugs integrated into several Jenkins projects, including Jenkins itself. I pushed draft PRs demonstrating what it will look like in a handful of plugins.

I put together information on my observation and recommendations for developers when they start working with findsecbugs. My blog post is at https://jenkins.io/blog/2020/03/02/findsecbugs/ and my Jenkins Online Meetup recording is available at https://youtu.be/fotttu20Mf4 .

Now we're ready to start pushing findsecbugs integration more widely, particularly into parent poms. StefanSpieker has had a PR for adding it into the Jenkins parent pom since November: https://github.com/jenkinsci/pom/pull/61 . It's time to get that moving forward.

Jeff

On 12/19/19 9:22 AM, Jeff Thompson wrote:

Yes, my goal is to also enable findsecbugs in the plugin parent pom. I think it's well worth it, just as regular spotbugs provides valuable findings in a number of cases.

I've currently got PRs awaiting review and approval for jenkins and remoting. I've got one approval for remoting so I'll proceed to merge that in before long.

I've also prepared branches for about half a dozen plugins where I've added it into their local configuration. I have planned on pushing those soon.

My idea is to prove it out with a selected set of projects and then work to roll it out more widely. I'm not sure how we want to proceed with adding it into the plugin parent pom. I'd like to just make it a standard part, but I think we might need to make it opt-in, such as with a profile, at least for an introductory period.

Thanks for the response,

Jeff

On 12/19/19 6:41 AM, Ullrich Hafner wrote:
If it helps to prevent some errors I think it would make sense to enable it for plugins as well (in the parent pom). Can the execution of this additional plugin be removed in a specific plugin pom afterwards? I’m not sure how maven handles it.

I enabled the checker in my plugins and needed to disable it for tests as there where too many false positives have been reported:

<Match>
  <Bug category="SECURITY"/>
  <Class name="~.*Test.*" />
</Match>

 Additionally, I deactivated the following rules that seem to produce too many false positives:

<Match>
  <Bug pattern="DESERIALIZATION_GADGET, FORMAT_STRING_MANIPULATION, PATH_TRAVERSAL_IN, WEAK_FILENAMEUTILS"/>
</Match>

Maybe it makes sense to gather feedback from some other plugins as well before changing the parent pom.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7e79e121-0962-da3a-8071-c37a0a05080a%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

James Nord-2
I would rather this did not get merged until after the 4.0 release of pom and have left further comment in the pr about the lack of reasonable opt out.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/75391b46-eec6-444f-9ca8-318bfb080941%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

Jeff Thompson
On 3/25/20 1:47 PM, James Nord wrote:
I would rather this did not get merged until after the 4.0 release of pom and have left further comment in the pr about the lack of reasonable opt out.

James, you're talking about the plugin parent pom, right? The current PR is for the Jenkins pom, which is currently at 1.55-SNAPSHOT.

Any idea when we'll move forward to the 4.0 release of the plugin pom?

Jeff

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1fa9591e-1889-b4f6-9f14-6a71dd3e211e%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: findsecbugs in spotbugs

James Nord-2
> James, you're talking about the plugin parent pom, right? The current PR is for the Jenkins pom, which is currently at 1.55-SNAPSHOT.


yes you are completely correct, my apologies.

> Any idea when we'll move forward to the 4.0 release of the plugin pom?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/268c03b4-7a62-42a9-8a7d-3ddb68bdb1a2%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

plugin patent 4.0

James Nord-2
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: plugin patent 4.0

Tim Jacomb
I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <[hidden email]> wrote:
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: plugin parent 4.0

Jeff Thompson

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:
I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <[hidden email]> wrote:
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com.
Reply | Threaded
Open this post in threaded view
|

Re: plugin parent 4.0

Mark Waite-2
I applied 4.0-beta-6 to the git client plugin as part preparation to set Jenkins 2.204.1 as the new required minimum version.  Worked great.  No issues detected.

On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson <[hidden email]> wrote:

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:
I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <[hidden email]> wrote:
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtF5Q9i6Fogmezxi6hoc3f1iOpj4b45NqzEn9KpVDi%2BwMg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: plugin parent 4.0

Oleg Nenashev
Hi all,

There was no new breaking changes coming in, and I think it is time to go ahead and release a 4.0 version.
I plan to do so tomorrow if there is no negative feedback.

It would be great if somebody could write a blogpost with a summary of the changes in the new major release

P.S: 4.0 works great in plugins I tried.

Best regards,
Oleg


On Monday, March 30, 2020 at 12:26:54 AM UTC+2, Mark Waite wrote:
I applied 4.0-beta-6 to the git client plugin as part preparation to set Jenkins 2.204.1 as the new required minimum version.  Worked great.  No issues detected.

On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="WeCxG4L1AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jtho...@...> wrote:

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:
I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="WeCxG4L1AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">james...@...> wrote:
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="WeCxG4L1AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkin...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="WeCxG4L1AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkin...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="WeCxG4L1AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkin...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: plugin parent 4.0

Tim Jacomb
This seems not to have happened, I'm happy to do it Oleg if you're too busy?

Thanks
Tim

On Mon, 6 Apr 2020 at 09:55, Oleg Nenashev <[hidden email]> wrote:
Hi all,

There was no new breaking changes coming in, and I think it is time to go ahead and release a 4.0 version.
I plan to do so tomorrow if there is no negative feedback.

It would be great if somebody could write a blogpost with a summary of the changes in the new major release

P.S: 4.0 works great in plugins I tried.

Best regards,
Oleg


On Monday, March 30, 2020 at 12:26:54 AM UTC+2, Mark Waite wrote:
I applied 4.0-beta-6 to the git client plugin as part preparation to set Jenkins 2.204.1 as the new required minimum version.  Worked great.  No issues detected.

On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson <[hidden email]> wrote:

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:
I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <[hidden email]> wrote:
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifaAfugnsG0BQpH3heqvPx7eY-KxhJX_xnmSjNLivy72w%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: plugin parent 4.0

Tim Jacomb
Hi

plugin pom 4 is now released,

Full release notes including all beta versions:

Thanks
Tim

On Wed, 15 Apr 2020 at 19:52, Tim Jacomb <[hidden email]> wrote:
This seems not to have happened, I'm happy to do it Oleg if you're too busy?

Thanks
Tim

On Mon, 6 Apr 2020 at 09:55, Oleg Nenashev <[hidden email]> wrote:
Hi all,

There was no new breaking changes coming in, and I think it is time to go ahead and release a 4.0 version.
I plan to do so tomorrow if there is no negative feedback.

It would be great if somebody could write a blogpost with a summary of the changes in the new major release

P.S: 4.0 works great in plugins I tried.

Best regards,
Oleg


On Monday, March 30, 2020 at 12:26:54 AM UTC+2, Mark Waite wrote:
I applied 4.0-beta-6 to the git client plugin as part preparation to set Jenkins 2.204.1 as the new required minimum version.  Worked great.  No issues detected.

On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson <[hidden email]> wrote:

+1

I don't remember if I've pushed any commits that use the beta parent, but I've tried it out on a variety of different plugins I've investigated. I've found it to work better than any of the other earlier versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:
I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <[hidden email]> wrote:
Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter) but I've been using it for numerous proprietary plugins with no issue.

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%40mail.gmail.com.
12