Jamie Tanna
29a7b9c5f5
To harden Renovate from being able to access internal hosts, we can add a level of enforcement on all outgoing requests. We can split this into two types of traffic: - where the response becomes configuration (i.e. `extends`) - where the response does not become configuration (i.e. `customDatasources`) To harden this, we enforce on every outbound HTTP request: - check the resolved URL before anything, including cache lookups, can proceed - catching IP-literal hosts in every spelling the WHATWG URL parser normalizes - blocking known Cloud metadata IPs, too - a `dnsLookup` wrapper validates every address a hostname resolves to, on every new connection, which also defeats DNS rebinding - a `beforeRedirect` hook re-runs the URL check on each redirect target, with the new host getting its own grant lookup rather than inheriting the original host's verdict We default this enforcement to `warn`, to not break existing deployments and instead give them visibility into required configuration before a future major version (major+1) enables `block` by default. We'll also remove allow in a future major version (major+2), to give time for admins to migrate over. When a request is blocked, this degrades like an unreachable registry, so a Renovate run isn't aborted by a blocked request. As part of this, we can also provide a worked example of the different cases that do/do not need allowing via `hostRules`. Requests through an admin-configured proxy resolve DNS at the proxy, so `dnsLookup` never runs for them, so we can resolve the hostname locally and validate every address before the request instead. This doesn't catch everything, especially as the proxy may resolve the name to a different result, and if we can't resolve the name - possible in locked-down corporate environments - we fail open. Child processes aren't currently able to route traffic through Renovate's HTTP layer, so are unrestricted. Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io> Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io> Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
Maven Central rate limiting and caching
Maven Central, hosted by Sonatype, receives a very large number of requests and has implemented rate limiting measures to manage organizational overconsumption. If you're experiencing 429 (rate limited) responses from Maven Central, you may need to optimize your caching strategy.
Renovate includes Maven caching optimizations, but they rely on having a persistent datasource cache. By default, Renovate uses a file-based cache, which means:
- Persistent environments (like self-hosted runners with persistent storage) will benefit from cross-run caching
- Ephemeral environments (like GitHub Actions or other CI/CD with fresh containers each run) won't benefit from caching across runs
To maximize caching effectiveness and reduce Maven Central requests:
- Use Redis for persistent caching: Configure a Redis instance for your Renovate datasource cache
- Ensure cache persistence: If using file-based caching, ensure the cache directory persists between Renovate runs
- Monitor rate limit warnings: Renovate will log warnings when receiving 429 responses from Maven Central
If you continue to experience rate limiting issues after implementing persistent caching, you may need to:
- Reduce the frequency of Renovate runs
- Consider using a Maven repository proxy with its own caching layer
!!! note
Dependencies that appear to be Gradle plugins (where the groupId or artifactId ends with .gradle.plugin) will not be looked up in Maven Central.
Making your changelogs fetchable
In case you are publishing artifacts and you want to ensure that your changelogs are fetchable by Renovate, you need to configure the scm section on their pom.xml file.
For example:
<scm>
<url>scm:git:https://github.com/path_to_repository</url>
</scm>
This is what allows Renovate to determine the sourceUrl, that it then uses to fetch the changelogs.
!!! note
This also works for private repositories.
It can leverage the same token that you had to configure in order to be able to reach the private Artifactory.
Specifying your project homepage
When opening a Pull Request Renovate uses the top level url property to determine the homepage of your project and shows it inside the Pull Request.
To customize you can set it inside your pom.xml.
For example:
<url>https://project.example.com</url>
latest and release tags
When latest or release values are present in a package's maven-metadata.xml, Renovate will map these to its tags concept.
This enables the use of Renovate's followTag feature.
However, Renovate will set respectLatest=false whenever the latest tag is found, because many Maven registries have been found to populate the tag unreliably.
You should use packageRules to set respectLatest=true if you wish to use this feature.