Comments inline:
> On 9/10/17 23:40, Priyanka Gugale wrote: > >> It's good idea to check for vulnerabilities, but as Pramod said all >> softwares / libraries are going to have some or other vulnerability at any >> time. I will go with approach of "let's discuss this addition" and we >> should not affect PRs which are not adding any new dependencies (due to >> old >> vulnerabilities). >> > While all software/libraries are subject to insecure code and > vulnerabilities, all software vendors whether open or close source > hopefully try to make code more secure rather than insecure. If there is an > existing or newly introduced dependency with a critical security issue, I > don't see why Apex community wants to accept the high probability of being > exposed to a security exploit. The only reasonable explanation for me is > that the community members do not care about overall project quality and > care only for tasks/PRs assigned to them by somebody else. I'll be glad to > hear a different explanation for the proposal not to penalize PRs that do > not introduce new dependencies and are affected by a newly found > vulnerability in an existing dependency. Will not we all be penalized later > if we don't fix it? > I take exception to the insinuation that (some) community members "care only for tasks/PRs assigned to them by somebody else". It is quite possible or likely that these members are eager to see new features, new functionalities, or new code added to the project because they get excited by such things. You need to take into account the mindset of people who are submitting PRs to add a new functionality or fix a bug. The PR author's focus correctly is on addressing that particular JIRA and ensuring that JIRA gets resolved at the highest quality. To burden that PR author with unrelated considerations of build systems, vulnerability findings and such is not fair. Note that the project is (or should be) primarily driven by users (and customers in case of vendors shipping this code in products) who use these features and pay for these features. So we need to balance the long term concerns about "security issues" and quality with the immediate term concerns about adding features and functionalities. > >> Also I also strongly feel, we need to be meticulous and think it through >> before introducing such checks for reasons discussed before. >> > +1. Equally applies to a newly introduced functionality and bug fixes. > Totally agree. However when we discuss or "think through" any concerns they should apply to the issue at hand (i.e. the newly introduced functionality and bug fixes) and not external factors. > >> -Priyanka >> >> >>>
