mirror of
https://github.com/renovatebot/renovate.git
synced 2026-11-03 02:53:40 +00:00
secustor
e63f40f8b3
`token` and `username`/`password` are not meant to be configured together, but
rank merging of a broad and a specific rule produces a rule carrying both, and
every consumer decided for itself what to do with one. Resolve it once, in
`resolveAuth()`, under a single documented precedence: a `password` wins over a
`token`, with `username` optional because HTTP Basic permits an empty user.
Adopted at the four formatters which already preferred Basic: the HTTP layer's
`applyHostRule()`, the docker datasource, composer's `auth.json` and bundler's
`BUNDLE_*` variables. `basicUserinfo()` and `basicAuthHeaderValue()` replace the
hand-rolled base64 in `util/http/auth.ts` and the docker datasource.
The precedence itself is unchanged at all four. Unifying what counts as a usable
Basic credential does change two of them for a rule that sets `password` without
`username`:
- the docker datasource now sends `Basic base64(":<password>")` for such a rule,
where it previously fell through to the rule's `token`, or sent no credentials
at all - covered by "supports basic authentication for a password without a
username" in lib/modules/datasource/docker/index.spec.ts
- composer now writes an `http-basic` entry with an empty `username` for such a
rule, where it previously wrote nothing - covered by "uses hostRules to set
COMPOSER_AUTH" in lib/modules/manager/composer/artifacts.spec.ts
Both now match what the HTTP layer has always done for the same rule, which is
what authenticates the corresponding lookup. bundler is unaffected, as its
`findAllAuthenticatable()` filter still requires a `username` alongside the
`password`.
`add()` registers the base64 of a password-only credential for sanitizing too,
so the header the widened cases produce is redacted from logs.
Datasources
Datasources are used in Renovate primarily to fetch released versions of packages.
Follow the class-based programming style
New datasources must follow the class-based programming style.
Use the java-version datasource as a reference.
Add the datasource to the API in api.ts so that the new datasource is usable.
If you find Unused HTTP mocks errors in the Vitest tests and your mocked URLs are correct, make sure the datasource is correctly registered.
getReleases
The minimum exported interface for a datasource is a function called getReleases that takes a lookup config as input.
The config has:
packageName: the package's full name including scope if present (e.g.@foo/bar)registryUrls: an array of registry URLs to try
getReleases should return an object having:
releases: an array of strings of matched versions. This is the only mandatory fielddeprecationMessage: a string description of the package's deprecation notice, if applicablesourceUrl: a HTTP URL pointing to the source code (for example on GitHub)homepage: a HTTP URL for the package's homepage. Ideally should be empty if the homepage andsourceUrlare the samechangelogUrl: a URL pointing to the package's changelog (could be a Markdown file, for example). If not present then Renovate will search thesourceUrlfor a changelog filetags: an object mapping tag → version, for exampletags: { latest: '3.0.0' }. This is only used by thefollowTagsfunction
getDigest
Datasources that support digests (like Docker digests and Git commit hashes) can export a getDigest function.
The getDigest function has two inputs:
config: the Renovate config for the package being updated, has the same fields asgetReleasesnewValue: the version or value to retrieve the digest for
The getDigest function returns a string output representing the digest value.
If no digest is found, the getDigest function should return null.