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/57b4a97a-945b-4180-ab33-a1a281689c9en%40googlegroups.com.
