Update insecure packages immediately, even when schedule is set

[openjck]

The schedule option can be used to force Renovate to wait until a given time before opening pull requests.

This can help cut down on noise, but developers who use this option risk missing critical security updates. For example, if Renovate is scheduled to update packages on Mondays, and a security update is published on a Tuesday, the project using Renovate might be insecure for 6 days.

I'd like to request that Renovate identify security updates and open pull requests for them immediately, even when a schedule is set.

[rarkins]

Hi @openjck, thanks for the suggestion. The key point is how to know when to do this, however this is definitely something I plan to do.

[rarkins]

Can we do this with a community-sourced set of packageRules to override schedules? It could be in the form of an opt-in preset.

Eg today there were node security releases for all supported streams. Basically anyone using node should upgrade.

But that doesn’t mean that node should be upgrade forever now (eg if there’s a job security patch tomorrow).

Maybe instead our rule should be a >= or < concept, ie override schedule of existing version is less than x.y.z. Little hard when something like node has multiple major versions at once, but most shouldn’t be like that.

Also we probably need to remove any groupName so that it doesn’t get mixed up with others that are non-urgent. Maybe also apply a label.

I suggest we design it as a preset but the option to include it is a native config option enabled/disabled.

[openjck]

I just discovered the nsp module, which flags insecure dependencies. I think they use https://nodesecurity.io/ under the hood.

[openjck]

I just discovered another neat addition to the ecosystem: synk. It looks like Renovate for security vulnerabilities. But I'm pretty loyal to Renovate and I'd love if it could do both at once. Plus it would be annoying to enable/configure yet another service for all of the repos I manage.

[rarkins]

nsp has been acquired and integrated with npm now. When you run npm install in latest versions it warns if there are any known insecure versions. We will capture/parse that output soon and use it in the PRs we raise. The main challenge is that many projects have deeply nested insecure dependencies that you often can't do much about, whereas most important to us are any direct dependencies with vulnerabilities because those can be upgraded.

[renovate-bot]

🎉 This issue has been resolved in version 13.37.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[rarkins]

This feature will become active in the Renovate App once additional permissions for reading vulnerability alerts are granted.

[karlhorky]

@rarkins so I guess #2321 added a feature to configure the security vulnerability PRs separately. What is not clear from this or the documentation is how a user would achieve resetting an existing schedule, as requested in this issue.

Trying to piece together the config documentation, maybe something like the following would work? The default schedule would be set to before 6am on friday, but for vulnerabilities, they would be opened at any time?

{
  "schedule": "before 6am on friday",
  "vulnerabilityAlerts": {
    "schedule": null
  }
}

[lkreimann]

Hi all, I have a question regarding the vulnerability alerts: Do they only work on GitHub or can I use them everywhere? I'm a bit confused by the text here: https://docs.renovatebot.com/configuration-options/#vulnerabilityalerts
It would be great to have vulnerability alerts on every platform, if that's possible at all.

[viceice]

Currently they only work for github, because it's implemented in platform.

[karlhorky]

@viceice @rarkins or based on this commit maybe it's something more like this?

{
  "schedule": "before 6am on friday",
  "vulnerabilityAlerts": {
    "schedule": "at any time"
  }
}

Got "at any time" from here: https://docs.renovatebot.com/configuration-options/#schedule

The default value for schedule is "at any time", which is functionally the same as declaring a null schedule. i.e. Renovate will run on the repository around the clock.

[rarkins]

I think either should work, and neither should be necessary. We have default schedule settings for alerts already.

[karlhorky]

neither should be necessary. We have default schedule settings for alerts already

Hm, really? Maybe this is a misunderstanding.

What I want to do is to override an existing schedule (eg. weekly) for vulnerabilities. I want vulnerability alerts to appear instantly.

For example, what do I need to add to this config to make vulnerability alerts appear immediately?

{
  "extends": [
    "config:base"
  ],
  "schedule": "before 6am on friday"
}

[viceice]

@karlhorky Use this:

{
  "extends": [
    "config:base"
  ],
  "schedule": "before 6am on friday",
 "vulnerabilityAlerts": {
    "schedule": null
  }
}

null is the default schedule, which is the same as at any time

@rarkins I don't find a default schedule for vulnerabilityAlerts

renovate/lib/config/presets/internal/default.ts

Lines 491 to 510 in a8f27e0

	enableVulnerabilityAlerts: {
	description: 'Raise PR when vulnerability alerts are detected',
	vulnerabilityAlerts: {
	enabled: true,
	},
	},
	enableVulnerabilityAlertsWithLabel: {
	description:
	'Raise PR when vulnerability alerts are detected with label <code>{{arg0}}</code>',
	vulnerabilityAlerts: {
	enabled: true,
	labels: ['{{arg0}}'],
	},
	},
	disableVulnerabilityAlerts: {
	description: 'Disable vulnerability alerts completely',
	vulnerabilityAlerts: {
	enabled: false,
	},
	},

[viceice]

Ok found this:

renovate/lib/config/definitions.ts

Lines 1202 to 1214 in 7651d2e

	name: 'vulnerabilityAlerts',
	description:
	'Config to apply when a PR is necessary due to vulnerability of existing package version.',
	type: 'object',
	default: {
	groupName: null,
	schedule: [],
	dependencyDashboardApproval: false,
	rangeStrategy: 'update-lockfile',
	commitMessageSuffix: '[SECURITY]',
	},
	cli: false,
	env: false,

Which should reset schedule.

[rarkins]

Let's not discuss things in 2+ year old closed issues any further though, we have a config help repo for this type of thing

[karlhorky]

@rarkins oh, really? That would be really cool! That's one of the most difficult thing about Renovate that I've experienced - the configuration is hard to piece together. The docs don't answer all questions that I have found myself asking about certain config options.

Googling usually leads to issues like this, which is why I've been trying to put together a lot of examples for those who are looking.

[karlhorky]

I guess you mean these issues in this here: https://github.com/renovatebot/config-help/issues

[rarkins]

PRs to improve the docs (which are open source, in this repo) are preferred over criticisms. Open source projects have makers and takers.. choose your path.

[karlhorky]

I think it's not that clear cut.

Re makers vs takers: It doesn't make sense for a lot of people to contribute out of time reasons. Furthermore, if someone is not comfortable with their knowledge on something, it's very difficult or impossible for them to contribute.

Re criticism: Non-toxic criticism is helpful for showing signals that something could be better. Sorry if I came over as toxic or negative. Renovate is awesome!

That said, I am already more on the end of the spectrum of "maker" (check out my contributions to open source if you want), and I will contribute to the Renovate docs, as soon as feel a bit more comfortable with my skills and the correctness of what I'm doing. I assume that the Configuration Options page is here: https://github.com/renovatebot/renovate/blob/master/docs/usage/configuration-options.md , is that correct?

[rarkins]

"The docs leave a lot to be desired." came across as non-constructive (toxic would not be a word I'd typically use, and definitely not here). I think most docs - open source or otherwise - could be improved greatly including ours, but in many ways ours are awesome. e.g. our linting rules mean it's impossible to add a config option to the product without a description for it, and the fact you need to add a subheading for it to the markdown doc too subtly encourages extended documentation too.

It's thankfully still the exception but as use of the project has grown, so too has the occurrences of people who act like they're owed or entitled to hand-holding, so anyway I also apologize that I lumped you into that group due to your comment. I did make sure to insert the word "project" after "open source" as people can be either in different contexts, myself included.

If a repo was source code only then I agree that some people simply can't contribute. But docs is another matter, and we have quite a lot of people who've proposed helpful edits to the markdown files without needing to even read a line of code.

The docs you see on the website are mostly all in the docs/usage/ folder and any approved PRs get automatically published pretty soon after. Any time you find it takes you more than one or two passes through the text to understand what it means, feel free to re-phrase or add to it to help the next user. Even if you're not sure of what's best feel free to raise a draft PR for feedback and we can suggest something better than what's there currently. If you feel really motivated about a particular topic, you can even create a new file on that topic as we don't have any fixed structure.

[karlhorky]

Understandable, I've reworded my original comment.

If you feel really motivated about a particular topic, you can even create a new file on that topic

Even if you're not sure of what's best feel free to raise a draft PR for feedback and we can suggest something better than what's there currently.

Will do, sure, if I get some time soon!

I think aside from clarity, some suggestions I would have would be:

1. List all possible configuration values, maybe also multiple times in the document
2. List of "common things you may want", such as some things listed by ljharb here: Guidance for initial default shared config? config-help#816
3. Split up the config docs into separate pages. This will help tremendously with search engine visibility.
4. A repo or folder full of config examples would also be helpful (or maybe this exists somewhere already?)

[rarkins]

1. List all possible configuration values, maybe also multiple times in the document

All possible configuration options are in that file. For the values, we try to auto-generate that information from https://github.com/renovatebot/renovate/blob/master/lib/config/definitions.ts as it's prepared for docs.renovatebot.com

2. List of "common things you may want", such as those listed by ljharb here: renovatebot/config-help#816

Yes, I agree that a most common topics doc could be useful. We need to offset the effects of overwhelming the typical user who just wants to get started (for whom which our config:base preset is intended). But also beware that ljharb is quite a power user so I wouldn't include all the things he's asking about there.

3. Split up the config docs into separate pages. This will help tremendously with search engine visibility.

We should maybe do that now, seeing as it's grown so large now. It would need to be done in https://github.com/renovatebot/renovatebot.github.io

4. A repo or folder full of config examples would also be helpful (or maybe this exists somewhere already?)

This kind of thing is hard to curate, as it starts growing large before long (it already grew too large around 2018-2019 so got absorbed into the regular docs).