Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turn Dependabot off

words.filippo.io

Post reply on HN
Print view View original

121–130 of 195 posts

Re: Turn Dependabot off

#121

Post by mechsy »

apitman wrote: post #41

I find dependabot very useful. It's drives me insane and reminds me of the importance of keeping dependencies to an absolute minimum.

Absolutely! This is oftentimes my first easy task in the morning to kick things off. For many teams the temptation to let dependencies ‚rot‘ is real, however I have found a reliable way to keep things up-to-date is enabling dependabot and merging relentlessly, releasing often etc.

If your test suite is up to the task you’ll find defects in new updates every now and then, but for me this has even led to some open source contributions, engaging with our dependencies’ maintainers and so on. So I think overall it promotes good practices even though it can be a bit annoying at times.

Re: Turn Dependabot off

#122

Post by ZiiS »

silverwind wrote: post #110
nfm wrote: post #17

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.

ReDoS is a bug in the regex engine. Still, V8 etc. seem to refuse to provide a ReDoS-safe regex engine by default.

Is the possibility to write an infinite loop in your language of choice a bug?

Re: Turn Dependabot off

#124

Post by solatic »

I sympathize with the author, and in principle I find myself nodding along with his prescriptions, but one of the benefits of Dependabot (and Renovate) are that they are language-agnostic. Depending on how many repositories, and how many languages, and upon whom the maintenance burden falls, there's a lot of value to be had. It may not really be feasible to add "the correct" CI workflows to every repository, and the alternative (nothing) inevitably ends up in repositories where dependencies have not been updated in years.

It's good optimization advice, if you have the time, or suffer enough from the described pain points, to apply it.

Re: Turn Dependabot off

#125

Post by silverwind »

Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

CodeQL seems to raise too many false-positives in my experience. And it seems there is no easy way to run it locally, so it's a vendor lock-in situation.

Re: Turn Dependabot off

#126

Post by 1718627440 »

woodruffw wrote: post #50
mirashii wrote: post #25

Earlier quoted context omitted.

> Is there an equivalent to govulncheck for say NPM or Python? There never could be, these languages are simply too dynamic.

In practice this isn’t as big of a hurdle as you might expect: Python is fundamentally dynamic, but most non-obfuscated Python is essentially static in terms of callgraph/reachability. That means that “this specific API is vulnerable” is something you can almost always pinpoint usage for in real Python codebases. The bigger problem is actually encoding vulnerable API information (not just vulnerable package ranges) i…

Idiomatic Python often branches on getattr to implement the interface and that is really hard to analyze from the outside.

Re: Turn Dependabot off

#127

Post by 1718627440 »

TZubiri wrote: post #29

Coming from someone with an almost ascetic dependency discipline, I look at some meta-dependencies as an outsider (dependabot, pnpm/yarn, poetry/venv/pipenv, snap/flatpak), a solution to too many dependencies that is yet another dependency, it feels like trying to get out of a hole by digging. I think that for FOSS the F as in Gratis is always going to be the root cause of security conflicts, if developers are not pa…

> for FOSS the F as in Gratis

Isn't FOSS a combination of the diverging ideas of "Open Source" and "Free Software"? The "Free" in "Free Software" very much does not mean "Gratis".

Re: Turn Dependabot off

#128

Post by 1718627440 »

Lichtso wrote: post #64
staticassertion wrote: post #31

Earlier quoted context omitted.

TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it…

> I Think that DoS needs to stop being considered a vulnerability Strongly disagree. While it might not matter much in some / even many domains, it absolutely can be mission critical. Examples are: Guidance and control systems in vehicles and airplanes, industrial processes which need to run uninterrupted, critical infrastructure and medicine / health care.

If availability is a security concern, than yes DoS is a security concern, but only in so far as all other bugs that limit availability are too. It is not a security concern per se, regardless of whether availability is a security concern. We don't treat every bug as a security issue.

Well, the Linux Kernel project actually does.

Re: Turn Dependabot off

#129

Post by DecoySalamander »

Twirrim wrote: post #74
nfm wrote: post #17

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.

I've been fighting with an AI code review tool about similar issues. That and it can't understand that a tool that runs as the user on their laptop really doesn't need to sanitise the inputs when it's generating a command. If the user wanted to execute the command they could without having to obfuscate it sufficient to get through the tool. Nope, gotta waste everyone's time running sanitisation methods. Or just ignor…

There is a plausible scenario in which a user finds some malicious example of cli params for running your command and pasts it in the terminal. You don't have to handle this scenario, but it would be nice to.

Re: Turn Dependabot off

#130

Post by talkin »

ZiiS wrote: post #122
silverwind wrote: post #110

Earlier quoted context omitted.

ReDoS is a bug in the regex engine. Still, V8 etc. seem to refuse to provide a ReDoS-safe regex engine by default.

Is the possibility to write an infinite loop in your language of choice a bug?

Most regex usage actually doesnt require near infinite backtracking, so limited unless opted in wouldn’t be that weird.
Post reply on HN