[Feedhenry-raincatcher] Snyk integration on the generated repos.

[Wojciech Trocki]

> Finally, I also vote for removing snyk's check in the release
repositories in favor of doing that in the monorepos no matter which of the
above options to integrate snyk we decide upon.

Agreed. Let's nuke this as this will give us false sense of the
security (while most of the packages will not be covered)

> I think for the main repositories we could use NSP's cli
<https://github.com/nodesecurity/nsp> in travis (assuming it exits non-zero
when a vulnerability is found, adding it would be very simple), and thus we
can have the checking be constant.
> So if upon a regular feature PR nsp sees that we have a vulnerable
dependency we can quickly open another PR to update it and rebase the
original one.

Used that before. That's really good idea! I will need to see the
difference between nsp vs snyk cli, but this doesn't matter really.
Updating packages is just trivial task.

The only problem with this aproach is when we do not do any PR builds for
some time, but I do not think that this will happen.
If checks will take long time we can also consider doing that on release
(as technically this when our code is impacting our community)

On Thu, Oct 12, 2017 at 4:54 PM, Paolo Haji <phajidec at redhat.com> wrote:

> Seems like the backporting was already acted upon, so +1 on that!
>
> I think for the main repositories we could use NSP's cli
> <https://github.com/nodesecurity/nsp> in travis (assuming it exits
> non-zero when a vulnerability is found, adding it would be very simple),
> and thus we can have the checking be constant.
> So if upon a regular feature PR nsp sees that we have a vulnerable
> dependency we can quickly open another PR to update it and rebase the
> original one.
>
> I was afraid Snyk's bot would have the same problem as greenkeeper of not
> supporting monorepos but there seems to be two alternatives:
>
> - Using the snyk cli <https://github.com/snyk/snyk> the same way we'd use
> the nsp cli, but it also requires extra authentication steps which can be
> configured in travis.
> However this way we'd need to update the packages ourselves like via the
> nsp route or pretty much reimplement the bot's PR features.
>
> - Manually adding every package.json in the monorepos to the list that the
> snyk bot checks as per https://github.com/snyk/snyk/issues/54
> This one is much simpler to do but adds a new manual step when creating
> new packages in the monorepos.
>
> Finally, I also vote for removing snyk's check in the release repositories
> in favor of doing that in the monorepos no matter which of the above
> options to integrate snyk we decide upon.
>
> On Thu, Oct 12, 2017 at 7:39 AM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> Hi
>>
>> We recently got integration on generated repositories.
>> Due to nature of this repos (all content is generated) we cannot really
>> merge any of the PR's as changes will be removed anyway with the next
>> release.
>> We should make this changes in the original source + best to react to
>> some critical problems.
>>
>> I have couple ideas how we can get that fixed:
>>
>> - Close PR's and backport changes to the core/angular.js repos.
>> - Disable synk on this repositories and have dependency check for recent
>> versions on release.
>> - Merge PR directly into the branch and then backport changes.
>>
>> I personally think that we may just need some general dependency update
>> process for the release + backport snyk changes.
>> NSP integration may be also useful - I wasn't as effective as Snyk, but
>> it's best to have it.
>>
>> Example PR: https://github.com/feedhenry-raincatcher/raincatcher-
>> portal/pull/1
>>
>> PS: We already have related ticket in the sprint:
>> https://issues.jboss.org/browse/RAINCATCH-1312 maybe we should extend
>> that?
>>
>> Regards
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> Feedhenry-raincatcher mailing list
>> Feedhenry-raincatcher at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>
>>
>
>
> --
>
> PAOLO HAJI
>
> SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
>
> Red Hat Brasil <https://www.redhat.com/>
>
> phaji at redhat.com
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>



-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20171012/fed74437/attachment.htm>