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 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/496a4b3a-0489-4783-b06b-1f27fd369bcan%40googlegroups.com.
