If a proxy URL appears to have a password component in it, we should
make sure that this is sanitised.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(util): note that `httpsCertificate` and `httpsCertificateAuthority` aren't secret
Although we're currently treating them as such, they're not technically
unsafe to appear in the logs, as a Certificate (and the authority) are
public.
* fix(util/host-rules): sanitise TLS credential fields in hostRules
We previously noted that the `httpsPrivateKey`, `httpsCertificate`, and
`httpsCertificateAuthority` fields would be marked as confidential, but
we weren't correctly sanitising them.
We can make sure that these fields are correctly flagged as secret
("confidential") and that they need to be sanitised when referenced.
Although the `httpsCertificate` and `httpsCertificateAuthority` aren't
secret, we can keep them sanitised for consistency with how we've
currently documented them as being sanitised.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* test(util/host-rules): ensure that all secret fields are marked as secret
As a way to make sure that new fields being added `HostRule`s are
considered as to whether the field should be marked as secret
("confidential") or not, we can add a test (and a compile-time
exhaustive check) to validate that `redactedFields` and
`confidentialFields` are kept in sync.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As we shouldn't really be using it, we should flag up usages more
clearly.
In cases where we do need to specify this - when
`allowShellExecutorForPostUpgradeCommands` is set - then we can disable
the rule.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As this is the only place in the codebase we're currently doing this, we
should remove the usage of `shell` semantics for file redirection, which
isn't needed.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* refactor(manager/github-actions): return dependency arrays from community `with:` schemas
A `withSchema` now yields `PackageDependency[]` directly, instead of a
`{ val, ...meta }` object whose extra fields were merged in through an untyped
`Record<string, unknown>`. Schemas describe the dependency they find, and a
single step may yield more than one.
`isInvalid` moves out of `CommunityActionConfig` into `valSchema`, its only
caller. The config fields are now applied to every dependency a schema yields.
No behavior change.
* feat(manager/github-actions): support `pnpm/setup`
`pnpm/setup` replaces `pnpm/action-setup` for pnpm 11+. Its `version:` input
resolves as the `pnpm` package, and its `runtime:` input as the JavaScript
runtime to install - `node`, `bun` or `deno`, named as `<name>@<version>` to
match pnpm's `packageManager` field syntax.
An unknown runtime name is skipped as `invalid-name`, so a typo does not pass
silently.
* ci: migrate to `pnpm/setup`
As part of ongoing issues we're seeing related to
https://github.com/pnpm/action-setup/issues/277, we've fixed this
upstream. However, while investigating, the README notes that the
`pnpm/setup` Action should be used for pnpm 11+.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! ci: migrate to `pnpm/setup`
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(config-validator): validate object entries in the `repositories` array
* Allow global configs in the repository object entry
* Simplify tests by combining them
* Allow `enabled` inside the repository entry
* Address review feedback
* Align type with #43295
* Skip validation for 'repositories' key in global config arrays
* refactor: flatten repositories array validation nesting
Address review feedback by combining the isArray and key checks
to avoid an extra nesting level.
* fix(schema): allow object entries in repositories array
Align renovate-global-schema with runtime: entries may be a string or
an object with required `repository` plus full global/repo config.
* Revert "fix(schema): allow object entries in repositories array"
This reverts commit 9aca8dcde8.
* fixups
* fix(config/validation): handle `allowedEnv` and `allowedHeaders` in `repositories`
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
* test(config): ensure that `errors` and `warnings` are always checked
As a follow-up to 6e411730a0, we can make
sure that we have a linter rule to make sure that this is consistently
checked.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* test(config/validation): ensure we don't use length checks
As it hides the actual messages, and makes it harder to know what is
being checked.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `onboardingConfig` example
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `module.exports` syntax
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: completely skip `doc-fence-check` on code blocks only used for synatx highlighting
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: skip schema validation on non-config snippets
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): validate JSONC and Javascript code blocks
To further ensure that our documentation is well-formed, we can validate
that JSONC and Javascript code blocks are well-formed syntactically, and
are valid Renovate configuration.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): allow opting out of syntax validation
On top of schema validation wanting to be disabled, we should also
support disabling the syntax validation, in the case that we're using
`json` code blocks for syntax highlighting, but they're not necessarily
well-formed JSON.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: use `json` syntax highlighting
As `jsonc` doesn't seem to exist in Material for MkDocs.
As it's only for syntax highlighting, we need to opt out of validation.
* tsc
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
For self-hosted users, we can provide an experimental override if they
need to opt back in.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of future changes, it would be useful to have a helper method to
handle the correct resolution for `Link` header parsing, where we want
to avoid the risk of a registry/platform providing a link to a different
hostname, which could lead to SSRF.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Jamie Tanna