Should there be a time limit imposed on shell commands?

Hello there👋

During my internal testing of `dependabot-core`, I discovered the following NPM issue: https://github.com/npm/cli/issues/6720

In a few words, when `npm` becomes unresponsive, `dependabot-core` also remains stuck indefinitely.

I'm unsure if there's a time limit in place for the hosted version of dependabot, but the problem can be easily replicated by directly running `dependabot-core` on the [reproducer ](https://github.com/yeikel/npm-infinite-loop-test/blob/main/.github/workflows/node.js.yml#L30-L31) as we run an unbounded command with `Open3.capture2e` : https://github.com/dependabot/dependabot-core/blob/0ba03f70d44fffd719501e3e4226c55715ec336c/common/lib/dependabot/shared_helpers.rb#L330-L337

Should we impose a time restriction on shell commands by default?

To address this specific NPM issue on a temporary basis, I've prepended [timeout](https://man7.org/linux/man-pages/man1/timeout.1.html) to the commands. This ensures that commands have a timeout, as demonstrated here: `timeout 10m $cmd`

I recognize the difficulty in identifying a universally effective timeout value for all projects and I also understand that this bug is likely temporary. However, I wouldn't be surprised if we encounter a similar issue in the future with any of our other native helpers

Start in common/lib/dependabot/shared_helpers.rb at the Open3.capture2e call, then run the linked npm infinite-loop reproducer to observe the unbounded command. Review the discussion and the proposed timeout 10m approach. Done requires an agreed default timeout policy that prevents a stuck native helper from blocking indefinitely without breaking commands that legitimately need longer.

Written by the indexing model from the issue text.