Hosting && Gavin Schedule

[Gavin Mogan]

This topic brings up a reminder I was going to bring up today. I like routines, so my routine for hosting (as long as it's just me) is every thursday I go through the hosting requests, run the checks, and approve things that have no outstanding issues. Thursday is the day. Best case it'll take a week (thursday to thursday) to approve, most likely it'll be 2 weeks.

> Could we at least make a rudimentary review mandatory before admitting plugins? The recent bunch of plugins had so many obvious problems, just pinging me and calling it a day isn't a good solution. We're worse than the Android App Store here.

Remember "we" is code for "someone not me"

So sure, someone other than you can do more in-depth reviews of the code. I've been doing absolute basic checks with the expertise I have. I was very clear when I took over the hosting lead position that I wasn't going to be spending much time doing reviews. I'm absolutely happy for someone to step up and do more code reviews.

But for now, that's my schedule. I'd love help from more experienced people.

Gavin

On Thu, Sep 16, 2021 at 7:07 PM db...@cloudbees.com (Jira) <nor...@jenkins.io> wrote:

There is 1 comment.   Plugin Hosting Requests / HOSTING-1133 To Do Request to host Keeper Secrets Manager plugin View issue   ·   Add comment   1 comment   Daniel Beck on 2021-09-16 18:56   There seems to be no reason for + in https://github.com/jsupun/keeper-secrets-manager-plugin/blob/5c63d56f0c066a2c47ba0da8401c929676723e58/src/main/java/io/jenkins/plugins/ksm/KsmSecret.java#L52 making this regex inefficient. Missing permission check in https://github.com/jsupun/keeper-secrets-manager-plugin/blob/51a7d547b994bd1ff066da4e7db807aa0dd385e4/src/main/java/io/jenkins/plugins/ksm/credential/KsmCredential.java#L121-L133 https://github.com/jsupun/keeper-secrets-manager-plugin/blob/63893eaa06e4f9e540eac2c5701169feff84565e/src/main/java/io/jenkins/plugins/ksm/builder/KsmBuilder.java#L187-L189 credentials enumeration vulnerability here Also here: https://github.com/jsupun/keeper-secrets-manager-plugin/blob/5c63d56f0c066a2c47ba0da8401c929676723e58/src/main/java/io/jenkins/plugins/ksm/builder/KsmBuilder.java#L187-L189 There being a separate step, rather than integrating with Credentials and just using withCredentials, is likely not great for secret masking in console output. https://github.com/jsupun/keeper-secrets-manager-plugin/blob/5c63d56f0c066a2c47ba0da8401c929676723e58/src/main/java/io/jenkins/plugins/ksm/builder/KsmBuilder.java#L172 unmodified sample plugin https://github.com/jsupun/keeper-secrets-manager-plugin/blob/main/src/main/java/io/jenkins/plugins/ksm/builder/KsmEnvironmentContributingAction.java#L46 that's not a user friendly name, why even bother? I have some reservations around KsmEnvironmentContributingAction. In contrast, credentials-binding uses a BuildWrapper that declares all variables to be sensitive (i.e. should not be shown on the UI). Could we at least make a rudimentary review mandatory before admitting plugins? The recent bunch of plugins had so many obvious problems, just pinging me and calling it a day isn't a good solution. We're worse than the Android App Store here.   This message was sent by Atlassian Jira (v8.13.5#813005-sha1:c18f263) Jira is improving email notifications, share your feedback! Get Jira notifications on your phone! Download the Jira Server app for Android or iOS.

[Daniel Beck]

> On 17. Sep 2021, at 04:32, 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> So sure, someone other than you can do more in-depth reviews of the code. I've been doing absolute basic checks with the expertise I have. I was very clear when I took over the hosting lead position that I wasn't going to be spending much time doing reviews. I'm absolutely happy for someone to step up and do more code reviews.

Thanks for starting this conversation.

My preferred option (that I mentioned in Jira) is to have a basic review of the plugin. My offer from August to give you access to the code scanning rules for plugins to quickly identify the low hanging fruit at least still stands. I haven't heard back from you about that.

Another option could be not have reviews, instead to do something similar to what Mozilla does[1], and prominently display that plugins are not reviewed for security. At least then we let admins know what they're getting. This would require criteria for other badges that need maintaining however, and certainly will take time to set up.

I'm sure there are other approaches we can take, but admitting code with very obvious security flaws doesn't seem like a great approach given how critical Jenkins is for many of its users.


1: https://support.mozilla.org/en-US/kb/add-on-badges

[Gavin Mogan]

I'm sorry I thought you were offering them up. I didn't realize you were asking if I wanted them. I can certainly try them out

As for the banner. It might be worth some sort of verified publisher or something else that indicates when the company maintains the plugin and you should contact thier support, vs community maintained plugins with community support avenues.

--
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/8E216E2D-EA35-4A21-99C8-44A026BFD592%40beckweb.net.

[Gavin Mogan]

I Lost track of where you did the ping to me. Sounds out I need to be clearer. if I get more scripts to run, I can run them before

[Gavin Mogan]

I can run them before approving  / reviewing them

In addition, i would like to help manage end users expectation about what kind of support a plugin might have (Core, Community, Professional, etc). Just one more thing to do on the todo list.

Gavin

[Robert Sandell]

I understand the case that we wan't to make sure users/administrators can somehow trust what is offered in the public/official update center.

But I don't like the idea of restricting or putting up barriers for new contributors to join the project, or hindering the potential innovation coming in from the outside. 

It was the welcoming and open approach of "just ask and you shall receive" that made me like this community so much and stay around for 11 years and hopefully many more.

There must be some way we can address both without sacrificing one?

So by all means, run the script to find the issues, but please don't block a contribution based on the findings from it.

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dusvy%3D0f_XCDrGpZ8FS5HmOdck4xORvtjdScfzc43iu3gQ%40mail.gmail.com.

--

Robert Sandell

Senior Software Engineer

CloudBees, Inc.

E: rsan...@cloudbees.com

Twitter: robert_sandell

[Slide]

We've been doing it for a long time already. Allowing insecure plugins into the infra creates a LOT of work for the security folks. I think it's a benefit to run the security checks to reduce that already heavy workload. It usually just takes a couple of back and forth discussions on Jira for hosting issues to get things resolved to cover most of the security issues. It's not a large barrier to overcome in my opinion.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3g-9xxNYc_MQRMwJVb%2BUbnJuc6hNHRwxE7VEJz7zE9EQ%40mail.gmail.com.

--

Website: http://earl-of-code.com

[Jake Leon]

Gavin,

This is a conversation I am very interested in. I think having a clear "tiering" system would be fantastic and was one of the first things on my plate to look into.

Do you think I can maybe set up a call with you, Mark Waite, Daniel and myself?

Thank you for bringing this up!

Jake