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
--
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/b1fde6e8-38df-4c4c-9da5-fbf616c2c099%40googlegroups.com.
On 12/12/19 7:10 AM, Jesse Glick wrote:
On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson <jtho...@cloudbees.com> 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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/54b09ff3-0494-4e30-8b32-b50cf144e654%40googlegroups.com.
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
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
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
yes you are completely correct, my apologies.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com.
+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
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com.
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 <jtho...@cloudbees.com> 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 <james...@gmail.com> 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 jenkin...@googlegroups.com.
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 jenkin...@googlegroups.com.
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 jenkin...@googlegroups.com.
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/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.com.
/James
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%40mail.gmail.com.
What I do not understand yet: do I still need to set the profile -Duse-jenkins-bom?
I updated all my plugins now, everything is looking good!Only problem: I needed to switch the minimum baseline to 2.204.4. I tried 2.190.4 but got a lot of errors. I’m not sure if this BOM version is expected to work as well.What I do not understand yet: do I still need to set the profile -Duse-jenkins-bom?Seems that everything works correctly without that...
Am 16.04.2020 um 21:38 schrieb Tim Jacomb <timja...@gmail.com>:
Hiplugin pom 4 is now released,Full release notes including all beta versions:ThanksTim
On Wed, 15 Apr 2020 at 19:52, Tim Jacomb <timja...@gmail.com> wrote:
This seems not to have happened, I'm happy to do it Oleg if you're too busy?ThanksTim
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 jenkin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%40mail.gmail.com.
Ok, I found the problem: maven-enforcer considered harmful. I don’t know how many hours I already spent fixing maven-enforcer library problems. The enforcer never found a real bug up to know, it is causing only confusion and so many lost hours of my valuable coding time :-(
The problem was the following dependency (from Jenkins 2.204.4) that I needed to add in the dependency configuration section of the POM to get the enforcer quite:
<commons.beanutils.version>1.9.4</commons.beanutils.version>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>${commons.beanutils.version}</version>
</dependency>
--
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/CANfRfr1DHp_8zRpaFAtFd4a6FjVBZLLdeerhZ3cNpDAjMS7arQ%40mail.gmail.com.
no. is that still documented somewhere? if so I need to remove it
Am 22.04.2020 um 00:26 schrieb James Nord <james...@gmail.com>:-Duse-jenkins-bom
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jenkins-ci.main:jenkins-bom:pom:2.150.1 in incrementals (https://repo.jenkins-ci.org/incrementals/)
--
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/CANfRfr0DFXCo1HH8xg2WfWfSAjM%3D2-U839%3D9365bw5Kxsu8%3DQQ%40mail.gmail.com.
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/exd3fc9NUAg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuNqxatsTiNXbrNpxnE%2B_mHZjwqxu9i3Qu5bTHhSP0Jig%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDE2fwANgoBk5dGBW%2BA0Mq0GDdOPraziNtFoc%2BT2uC1GA%40mail.gmail.com.
Am 23.04.2020 um 01:06 schrieb 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com>:I'll update to 2.164, or tell dependabot to ignore this dep.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusvB1sDb3wSwHFV2RK6JZKZsPAfTmcth18c%2Bh%2BCAn5Sgg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/25823FF0-3E4A-41D1-A6DD-E98989E27F97%40gmail.com.