| 18:12 | <bakkot_> | mathiasbynens: npm claims you have publish permissions for lodash; do you actually? and if so are you socially permitted to merge and release patches to it? JDD has been not filling that role lately and it is coming to a head this morning because npm has marked it as having a vulnerability, which causes problems for anyone with strict audit requirements and who transitively depends on lodash |
| 19:05 | <leobalter> | I've been thinking in setting a regular regionalized meeting to get feedback from developers speaking pt-br. We've had one similar to this in spanish and it worked great. I wonder where is the proper channel to continue this convo, the Reflector or Discourse. |
| 19:06 | <leobalter> | In any case, let me ping here caiolima mmarchini... am I missing anyone else online in this channel? We also have Sam Goto, Gui Hermetto, Romulo Cintra. |
| 19:15 | <mmarchini> | sounds good (i don't look at IRC that much though) |
| 21:41 | <ljharb> | sigh, prototype pollution CVEs are one of the best examples of how the security industry undermines the very concept of CVEs by targeting things too broadly :-/ |
| 21:57 | <bradleymeck> | ljharb: there really needs to be a filter on what prototypes can cause the issue |
| 21:57 | <bradleymeck> | but as long as everything remains mutable 🤷 seems like they are doing the correct thing, even if it is noisey |
| 22:00 | <ljharb> | i don't agree they are; the bug isn't in lodash, it's in the *usage* of lodash |
| 22:01 | <ljharb> | imo this is the category of thing where "it can be misused" may be something undesirable, but isn't an actual security issue |
| 22:01 | <ljharb> | but for the small percentage of non-top-level consumers for whom it was an issue, it's a CVE for sure |
| 22:02 | <bradleymeck> | and that's why it should be a CVE |
| 22:02 | <ljharb> | it should be a CVE for someone, i agree |
| 22:02 | <bradleymeck> | you can't really CVE all the consumers of a library but you can CVE the library |
| 22:03 | <ljharb> | you can't achieve it but that's still the correct thing to do |
| 22:03 | <bradleymeck> | and marking all consumers as needing to validate what they pass is the method to get things done, but you can't say they are fixed, you can only mark the issue as mitigated by the lib |
| 22:03 | <ljharb> | iow they made the choice to create false positives, rather than risk missing real ones |
| 22:03 | <bradleymeck> | i don't agree it is the correct thing to do |
| 22:03 | <ljharb> | but the cost of making this tradeoff repeatedly *already is* that people are going to just turn off the CVEs |
| 22:04 | <ljharb> | not because they're noisy, but because for most consumers there simply isn't an issue |
| 22:04 | <bradleymeck> | false positives are noise but it is still the choice to disable the warnings |
| 22:04 | <ljharb> | imo it's better for the industry as a whole to allow real positives to go unnoticed than to undermine ecosystem acceptance of the CVE system itself by creating too many false positives |
| 22:04 | <bradleymeck> | consumers have to check if it is an issue to know if it isn't one |
| 22:05 | <ljharb> | (it works the same with linters; if the linter is too noisy and it doesn't feel like a real problem, people just turn off the rule/linter) |
| 22:05 | <ljharb> | right but they don't check, just like they don't read the itunes TOS |
| 22:05 | <ljharb> | sorry this is all really off topic for the channel, we can take it to tdz |
| 22:05 | <bradleymeck> | i think you want something other than a CVE, CVE is just reporting the issue not stating it affects every consumer |
| 22:06 | <ljharb> | fair. but github, snyk, npm audit, and all the other tools automatically assume CVE implies report |
| 22:17 | <devsnek> | which one is the one that can analyze the usage of code |
| 22:18 | <ljharb> | LGTM maybe? but github bought them and shut it down, and has a new beta for "codeQL" to replace it |
| 22:18 | <ljharb> | (sorry, didn't shut it down; just stopped touching it) |
| 22:18 | <devsnek> | ok so yeah they just need to attach codeql to their CVEs |
| 22:19 | <devsnek> | so it knows who to notify |
| 22:19 | <ljharb> | sounds like a bit more than "just" but that sounds like it'd be great :-) |
| 22:19 | <devsnek> | easy 15 minute task |
| 22:19 | <bradleymeck> | we have some code pattern matchers, they are too fragile |
| 22:19 | <bradleymeck> | it would still blast 90% probably |
| 22:20 | <devsnek> | have you tried lgtm.com |
| 22:20 | <devsnek> | its incredibly accurate |
| 22:20 | <devsnek> | s/incredibly/surprisingly/ |
| 22:21 | <bradleymeck> | not that one but things like knowing what values could be passed to _.get is... pretty big |
| 22:32 | <ljharb> | devsnek: it's quite inaccurate on es-abstract |
| 22:32 | <ljharb> | devsnek: on enzyme too |
| 22:32 | <ljharb> | devsnek: they have a number of heuristics that don't actually hold true in edge cases |
| 22:34 | <devsnek> | the only one i ever caught was document.all |