FTR we created the new *#lfx-security-2-pilot-with-snyk* channel in the CDF Slack workspace so that all sides can sync-up in a chat if needed. You can join the workspace by following the guidelines in https://www.jenkins.io/chat/#continuous-delivery-foundation All interested contributors and maintainers are welcome!
On Wednesday, May 5, 2021 at 10:25:50 PM UTC+2 Oleg Nenashev wrote: > UPD: The Jenkins Governance meeting approved official participation in the > Pilot project. > Approved by: Ulli Hafner, Gavin Mogan, Ewelina Wilkosz, Daniel Beck, > Baptiste Mathus, Mark Waite (+ Olivier I'd guess) > Thanks everyone for the feedback! > > > On Wednesday, May 5, 2021 at 7:28:36 PM UTC+2 Oleg Nenashev wrote: > >> Hi all, >> >> Just a quick update, we will be setting up a shared Slack channel in the >> CDF workspace. Once it is ready, we can use it for conversations. >> Pending ticket to the CDF: >> https://github.com/cdfoundation/foundation/issues/330 >> >> BR, Oleg >> >> On Tuesday, May 4, 2021 at 9:30:06 AM UTC+2 Oleg Nenashev wrote: >> >>> Hi Olivier, >>> >>> For experiments, it might make sense to register Jenkins Infrastructure >>> as the second organization. I do not anticipate major overlap between >>> configs taking different technology stacks. >>> Once Snyk adds support for multiple GitHub orgs, we can explore our >>> options. M<aybe it won't be even a problem since we can unlikely use the >>> standard GitHub App integration anyway (see my response to Daniel) >>> >>> If you want to start with the Jenkins Infra org, I think you can do it >>> even now on LFX Security 1.x && standard GitHUb integration. Then it can be >>> migrated to 2x. >>> Let the LFX Security team know if you want one to be created. >>> >>> Best regards, >>> Oleg >>> >>> >>> On Tue, May 4, 2021 at 8:46 AM 'Olblak' via Jenkins Developers < >>> [email protected]> wrote: >>> >>>> Hi Oleg, >>>> >>>> Thanks for driving this. >>>> Once we are allowed to have a second Github Organization, I would be >>>> very interested to experiment with it for the jenkins-infra organization. >>>> >>>> On Monday, 3 May 2021 at 22:24:44 UTC+2 Oleg Nenashev wrote: >>>> >>>>> Thanks for the interest Daniel! >>>>> >>>>> >> Would you like to participate as a contributor? >>>>> > What does this entail? >>>>> >>>>> That's a good question, to be seen. As a part of the pilot project we >>>>> will need: >>>>> >>>>> - Try out LFX Security 2.0 and configure it for some of our >>>>> projects >>>>> - Explore options for filtering out false positives, find a >>>>> solution for the Jenkins project taking its scale and needs >>>>> - Try out other features like license analysis >>>>> - Document the implementation for other maintainers >>>>> - Keep evaluation notes and share feedback with Snyk/LFX Security. >>>>> If we experience blockers, multiple iterations might be required >>>>> >>>>> Note from the discussion: It is unlikely that we will be able to use >>>>> the standard Snyk's GitHub integration via GitHub App. We will likely >>>>> need >>>>> to integrate scanning submissions into our Jenkins pipelines (there is a >>>>> Snyk plugin FTR) or to use GitHub actions. Reason - GitHub Integration >>>>> cannot handle custom Bills of Materials which will be supported by the >>>>> LFX >>>>> Security 2.0 API (actually, by the Snyk backend). >>>>> >>>>> > Re licenses -- Is this something we're actively looking at as well, >>>>> or rather secondary. FWIW I can think of these use cases: That it's >>>>> actually open source; that it's compatible (no MIT plugin bundling GPL >>>>> dependencies or similar weirdness); that it's all OSI approved per >>>>> governance document. Anything else? >>>>> >>>>> Yes, looks good to me. I would rather prefer to avoid some licenses >>>>> where compatibility is disputed, e.g. traditional AGPL concerns. >>>>> >>>>> >>>>> On Monday, May 3, 2021 at 9:35:17 PM UTC+2 Daniel Beck wrote: >>>>> >>>>>> Thanks again for driving this, Oleg! >>>>>> >>>>>> >>>>>> > On 3. May 2021, at 19:14, Oleg Nenashev <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > The proposal is to start the pilot from a small list of the >>>>>> repositories controlled by the pilot project participants: Jenkins core, >>>>>> its libraries, and some plugins from maintainers who are interested to >>>>>> participate in the pilot project. >>>>>> > >>>>>> > Call for feedback: >>>>>> > • Would you approve doing an official pilot project together with >>>>>> Snyk and LFX Security? >>>>>> >>>>>> Yes, definitely. >>>>>> >>>>>> > • Would you like to participate as a contributor? >>>>>> >>>>>> What does this entail? >>>>>> >>>>>> > • Would you like your plugin to participate in the pilot project? >>>>>> >>>>>> Yes (although my plugins tend not to have interesting dependencies so >>>>>> it's probably not that interesting). >>>>>> >>>>>> >>>>>> Re private PRs and security process (minute 25-28 in the transcripts, >>>>>> again around 0:51) -- I don't really see a need to handle dependency >>>>>> updates in private in most cases, as all information that is based on is >>>>>> usually public anyway (CVEs in dependencies as well as dependency >>>>>> declarations). Additionally, vulnerabilities in plugins don't >>>>>> necessarily >>>>>> mean we're vulnerable (or that the metadata is correct to begin with), >>>>>> and >>>>>> how to exploit it isn't often obvious either. So I don't feel strongly >>>>>> about keeping such content private. What we prepare in jenkinsci-cert in >>>>>> private is almost exclusively fixes for exploitable vulnerabilities >>>>>> originating in Jenkins code. >>>>>> >>>>>> Re CVE ignore list and such -- would like to see a plan (perhaps with >>>>>> the custom graph API that pre-filters plugin dependencies) how to deal >>>>>> with >>>>>> transitive plugin dependencies: Plugin X depends on plugin Y which >>>>>> bundles >>>>>> library Z. The maintainer of X doesn't really care about Z being >>>>>> outdated. >>>>>> (The same applies to "core Y" -- no need for a tool to tell plugin >>>>>> maintainers about core dependencies being outdated.) While we could dump >>>>>> all Jenkins CVEs into a giant ignore list, that wouldn't take care of >>>>>> this >>>>>> problem. >>>>>> >>>>>> Re licenses -- Is this something we're actively looking at as well, >>>>>> or rather secondary. FWIW I can think of these use cases: That it's >>>>>> actually open source; that it's compatible (no MIT plugin bundling GPL >>>>>> dependencies or similar weirdness); that it's all OSI approved per >>>>>> governance document. Anything else? >>>>>> >>>>>> -- >>>> 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/lIeGyefi1Y4/unsubscribe >>>> . >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/496a4b3a-0489-4783-b06b-1f27fd369bcan%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/496a4b3a-0489-4783-b06b-1f27fd369bcan%40googlegroups.com?utm_medium=email&utm_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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9eab0374-4484-40c9-acbe-ba9c84ab0da4n%40googlegroups.com.
