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/1d8cdad1-3422-408c-9418-ea5d49a6f27bn%40googlegroups.com.
