git push --no-verify should be configurable

[fgblomqvist]

What would you like Renovate to be able to do?

By default, since #6521, renovate runs git push with the option --no-verify. This skips any pre-push hooks, as well as hooks on the receiving end. It shouldn't be default to do this, since people might have important checks that maintain their repo integrity. If people want to bypass their own checks, fine, makes sense, however, that should be a flag you turn on in Renovate. E.g. you deliberately say "skip my hooks". I'm fairly certain that it's a minority that need to skip their hooks, which is why it makes sense to default the behavior to just running things like usual.

Did you already have any implementation ideas?

Add a new config option on a repo-level, something like verifyPush (please suggest a better name if you know one lol) that decides whether you add --no-verify to the git push commands.

I'm fine with pushing a PR to do this. It's technically a breaking change however, last time around it was not counted as a breaking change 🤷

[fgblomqvist]

Background:
I finally got to the bottom of why LFS wasn't working. We installed LFS inside our renovate image but we'd still get errors when renovate tried to push a branch with changes to an LFS file. Turns out that since --no-verify is passed to git push, it skips the pre-push hook installed by LFS (which runs git lfs pre-push "$@"). Which in turn will cause the receiver to complain.

However, I find the argument in the original post here to be stronger and more general, just figured I'd put this here because if this doesn't get fixed, it's impossible to run Renovate in an LFS repo without adding official full-blown LFS support to Renovate. Linking #6842 for visibility.

[sgtsquiggs]

In our use-case we publish project-lock.json files using lfs due to their size. When renovate updates the file, it pushes it without using LFS which fails due to our non-lfs file size limit.

[viceice]

I see some big security concerns allowing git hooks in renovate. It would allow a bad user to execute malicious code in renovate context.

I would prefer to move git operations to a separate docker sidecar container first.

We should only allow hooks in self-hosted mode until we have a safe method to allow hooks, so they can't attack us.

This would be same reason why we don't allow npm / renovate postupdate / ... scripts in hosted app.

[fgblomqvist]

@viceice maybe I'm missing something but running git commit or git push without the --no-verify option doesn't magically install hooks for you?

If that was true, it would be a security flaw in git itself 😅.

If you're running Renovate in a context where you installed hooks yourself (e.g. in a Dockerfile, or on a dev machine) it is obviously your responsibility to make sure those hooks are okay.

[viceice]

I know by default there are no local hooks after git checkout, until you call a script to installl them, which can be eg husky at npm prepare script (but can be done by any external binary we call for artifacts).

So we currently cant be always sure that no script is addind hooks, so we disabled them to be more safe.

I see we can use trustLevel (will renamed soon in v25) to allow hooks running in self-hosted renovate. I'm not sure we can allow runnings hooks in hosted app.

Maybe @rarkins can give some feedback too.

[rarkins]

One possibility (naming is flexible of course) could be this:

• An admin option called allowGitHooks which defaults to false
• A user-configurable runGitHooks which also defaults to false, but an admin could switch to default true

If both are true at runtime then the no verify option can be dropped.

For the app, we would keep it to false until a future refactoring which runs any risky git command within its own container.

[rarkins]

BTW there also needs to be a way to surface these errors to the repository, e.g. via the Config warning issue. Otherwise errors might go unnoticed

[fgblomqvist]

Is the security implication here that someone might install a hook, that gets run for others' repos (in the hosted version)? Because otherwise I'm assuming that code that runs in e.g. an npm script is equally dangerous to code that runs in a hook it installs (if it's just in the same repo)?

Either way, what @rarkins said sounds fine to me. What are "admin" options vs. "user-configurable" options?

[viceice]

Is the security implication here that someone might install a hook, that gets run for others' repos (in the hosted version)? Because otherwise I'm assuming that code that runs in e.g. an npm script is equally dangerous to code that runs in a hook it installs (if it's just in the same repo)?

That why npm scripts are also disabled on hosted renovate app and also for self-hosted by default (can be allowed by allowScripts, see below)

Either way, what @rarkins said sounds fine to me. What are "admin" options vs. "user-configurable" options?

renovate/lib/config/definitions.ts

Lines 475 to 482 in 572749a

	{
	name: 'allowScripts',
	description:
	'Configure this to true if repositories are allowed to run install scripts.',
	admin: true,
	type: 'boolean',
	default: false,
	},

Those admin options can only be set by bot admin. You can easily search the code for allowScripts usage.

[fgblomqvist]

That why npm scripts are also disabled on hosted renovate app and also for self-hosted by default (can be allowed by allowScripts, see below)

Alright makes sense. So the purpose of disabling hooks from running is in case someone finds a way to manage to install hooks? But if someone finds a way to install hooks, can't you argue that they can already execute arbitrary code at that point? E.g. if they can install hooks, they can probably put scripts in a lot of different places (and run various things).

Those admin options can only be set by bot admin.

Hmm okay, thanks.

[renovate-release]

🎉 This issue has been resolved in version 25.23.0 🎉

The release is available on:

• GitHub release
• 25.23.0

Your semantic-release bot 📦🚀