feat(manager/pixi): gate pixi.lock updates behind allowedUnsafeExecutions
The pixi manager runs `pixi lock`, which can execute arbitrary code from
conda package hooks. It now only updates `pixi.lock` when `pixi` is
included in the global `allowedUnsafeExecutions` option, following the same
pattern as the `mise` manager. When `pixi` is not allowed, the package file
is still updated but `pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
* ci: add local mkdocs-admonitions plugin for prettier to allow admonition preservation
* docs: remove uses of `prettier-ignore` for admonitions
* test: rather use await expect
* chore: use named group exclusively
As noted in #39090, MkDocs requires 4 spaces for indentation (in
particular, for nested lists) whereas our Prettier/markdownlint
configuration expects 2 spaces.
This means that when trying to use i.e. nested lists, we need to ignore
prettier and markdownlint, otherwise it fails.
To handle this, we can add a Markdown hook to override the indentation
level to 2 spaces.
This also requires we update:
- admonitions
- indented text in `index.md`
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As a safety measure for self-hosted administrators, we can make sure
that we set `allowedUnsafeExecutions` to not allow any commands by
default.
This closes off a significant risk of executing Gradle Wrapper
commands, which use the repository's copy of the wrapper, and any
Gradle buildscript, when executing, which can lead to significant remote
code execution, even before you take into account malicious dependencies.
As this is now off-by-default, we can enable it by default in our tests
to make sure that there are minimal changes required.
To make sure that we're using secure defaults, we can make sure that
this is off-by-default.
Self-hosted administrators will be able to turn this back in if they
wish.
As part of hardening the configuration around executing
`postUpgradeTasks` with `shell: true`, we can give self-hosted
administrators the opportunity to configure this.
This continues to be on-by-default to be non-breaking, but in the next
major version can be flipped to the safer option.
As part of ongoing efforts I'm taking to make Renovate have more
secure-by-default settings, we should document some of the additional
risks that can occur when self-hosting.
This primarily focusses on outsider attacks (i.e. from a malicious
dependency) as we're finding is increasing in frequency in the recent
years.