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 <o.v.ne...@gmail.com> 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 the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/496a4b3a-0489-4783-b06b-1f27fd369bcan%40googlegroups.com.
