Skip to content

Remove historical documentation #2822

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
timja merged 2 commits into from
Apr 9, 2026
+0 −23
Merged

Remove historical documentation #2822

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5ab12d0
Add SECURITY-1446 advisory link to secrets documentation
somiljain2006 Apr 9, 2026
2b199cb
Removal of whole section
somiljain2006 Apr 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 0 additions & 23 deletions docs/features/secrets.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -150,29 +150,6 @@ Example:
${trim:${readFile:/secret/passphrase.txt}}
```

=== Security and compatibility considerations

// TODO(oleg_nenashev): Add a link to the advisory once ready

Jenkins configurations might include property definitions,
e.g. for Token Macro resolution in Mail Ext Plugin.
Such properties are not supposed to be resolved when importing configurations,
but the JCasC plugin has no way to determine which variables should be resolved when reading the configurations.

In some cases non-admin users can contribute to JCasC exports if they have some permissions
(e.g. agent/view configuration or credentials management),
and they could potentially inject variable expressions in plain text fields like descriptions
and then see the resolved secrets in Jenkins Web UI if the Jenkins admin exports and imports the configuration without checking contents.
It led to a security vulnerability which was addressed in JCasC `1.25` (SECURITY-1446).

- When reading configuration YAMLs, JCasC plugin will try to resolve
**all** variables having the `${VARNAME}` format.
- Starting from JCasC `1.25`, JCasC export escapes the internal variable expressions,
e.g. as `^${VARNAME}`, so newly exported and then imported configurations are
are not subject for this risk
- For previously exported configurations, Jenkins admins are expected to manually
resolve the issues by putting the escape symbol `^` in front of variables which should not be resolved

=== Secret sources

In JCasC there is a link:https://jenkins.io/doc/developer/extensions/configuration-as-code/#secretsource[SecretSource extension point] which allows resolving variables passed to JCasC.
Expand Down
Loading