Renovate: Automerge with delay

Created on 26 Nov 2018  路  2Comments  路  Source: renovatebot/renovate

Saw this idea on another project and figured it'd make sense for Renovate to have it to.

Ref: https://github.com/dependabot/feedback/issues/108

priority-3-normal feature

Most helpful comment

I think the better solution to wait before even raising the PR - no point having one sitting around "noisily". Some of the exploits have been attempting to steal credentials off CI too.

For npm we have the concept of "unpublishSafe" which delays all updates by 24 hours until the package can be unpublished. It could be extended to allow arbitrary (configured) delays. But recall that in this latest exploit the package was around for months before this was noticed, so no reasonable delay would have helped.

All 2 comments

I think the better solution to wait before even raising the PR - no point having one sitting around "noisily". Some of the exploits have been attempting to steal credentials off CI too.

For npm we have the concept of "unpublishSafe" which delays all updates by 24 hours until the package can be unpublished. It could be extended to allow arbitrary (configured) delays. But recall that in this latest exploit the package was around for months before this was noticed, so no reasonable delay would have helped.

@OmgImAlexis an alternative approach recently employed by Dependabot, and mentioned in their most recent blog post, is to mention, as part of a pull request description, when the maintainer of a package on the Npm registry has been added.

It _could_ help mitigate future incidents such as event-stream (assuming you block auto-merging until you've reviewed the changes made by the new maintainer, including sub dependencies that maintainer may have added).

Though, I'm still concerned, as even this particular technique would be trivial for an attacker to circumvent. An attacker could publish a few legitimate releases before publishing an exploit.

Perhaps we could extend the approach by indicating the reputation of a new maintainer by the volume of the npm ecosystem dependent on their packages. Though, that might create a feedback mechanism that leads to people not depending upon, or using, packages belonging to new maintainers.

I, too, would really like to see mechanisms in place that mitigate the risk of core modules being controlled by motivated attackers, but it seems difficult to come up with a solution that isn't easily circumvented, or with negative side-effects.

Was this page helpful?
0 / 5 - 0 ratings