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/bb188d8e-1a09-4837-84a9-b82c62d3c4fbn%40googlegroups.com.
