* Add support for hudson.model.Failure in CLI error output
* Fix Javadoc
* confirm the "unexpected" message does not show
* Adapt tests to changed behavior
---------
Co-authored-by: Daniel Beck <daniel-beck@users.noreply.github.com>
* Propagate readOnlyMode into SCM Checkout Strategy descriptor config
f:dropdownDescriptorSelector renders its selected descriptor's config.jelly
lazily via AJAX (lib/form/dropdownDescriptorSelector.jelly), and only
variables listed in its `capture` attribute are visible to that lazily
rendered fragment. hudson/model/Job/configure.jelly sets readOnlyMode for
the whole config page, but lib/hudson/project/config-scm.jelly's call for
scmCheckoutStrategy didn't capture it, so a Job's SCM Checkout Strategy
config fragment was not disabled for read-only viewers (Item.READ +
Item.EXTENDED_READ, no Item.CONFIGURE), even though every other field on
the page correctly disables in that case.
This mirrors the same gap that was originally found and fixed in
cloudbees-folder-plugin (JENKINS-62218,
jenkinsci/cloudbees-folder-plugin#747) and reverted there since it's a
core issue affecting every Job configuration page, not just folders. Part
of the JENKINS-12548 read-only system configuration browsing epic
(JEP-224). No Jira ticket filed yet for this specific core gap.
* Propagate readOnlyMode to remaining dropdownDescriptorSelector fragments
f:dropdownDescriptorSelector defers rendering of every non-selected
descriptor's config.jelly/config.groovy via l:renderOnDemand, which only
forwards variables named in its `capture` attribute into that later
AJAX-rendered fragment. readOnlyMode (JEP-224, JENKINS-12548) is not
forwarded by default, so a viewer with Item.EXTENDED_READ but not
Item.CONFIGURE can get back a fully editable fragment for any option other
than the currently selected one, even though the rest of the page correctly
disables.
The gap was first found and fixed for the SCM Checkout Strategy dropdown on
Job/configure.jelly (previous commit, also reported against
cloudbees-folder-plugin#747 / JENKINS-62218 and reverted there as a core
issue). Review of that fix pointed out the bug is generic to
dropdownDescriptorSelector, not specific to SCM Checkout Strategy. This
commit closes the remaining Job/agent-configuration-scoped call sites found
by auditing all *.jelly and *.groovy usages of the tag in core:
- HudsonPrivateSecurityRealm/config.jelly (Password Complexity Rule)
- DelegatingComputerLauncher/config.jelly and DumbSlave/configure-entries.jelly
(agent Launch method, Availability/retention strategy)
- Maven/config.jelly (Settings file, Global Settings file build-step config)
- GlobalFingerprintConfiguration/config.jelly (Fingerprint Storage Engine)
- BuildDiscarderProperty/config-details.jelly and
SimpleGlobalBuildDiscarderStrategy/config.jelly (Discard old builds strategy,
at both the per-job and global-default nesting levels)
- GlobalMavenConfig/config.groovy (default settings/global settings provider)
- ViewsTabBar/GlobalConfigurationImpl/config.groovy (Views Tab Bar)
- GlobalCrumbIssuerConfiguration/config.groovy (Crumb Issuer)
hudson/model/MyViewsProperty/config.jelly (Views Tab Bar on a user's own
account page) was deliberately left out: that page requires full
Jenkins.ADMINISTER and never sets readOnlyMode in its render chain, so it is
not an instance of this bug.
A further instance of this same gap exists on the "Manage Jenkins > Security"
page (Security Realm / Authorization Strategy / Markup Formatter selectors),
reachable with only Overall.SYSTEM_READ. That one is being reported through
the Jenkins Security Team's private disclosure process instead of here, since
it can expose an editable Security Realm/Authorization Strategy fragment to a
low-privilege viewer -- a permission-escalation-adjacent issue rather than a
plain read-only-UI gap.
Adds a regression test (SCMCheckoutStrategyReadOnlyModeTest) that registers a
throwaway SCMCheckoutStrategy with a real editable field, triggers the same
renderOnDemand() JS a browser fires when switching the dropdown, and asserts
the resulting fragment is rendered as the standard read-only N/A placeholder
rather than an editable input.
* Propagate readOnlyMode to GlobalSecurityConfiguration's dropdownDescriptorSelector calls
Applies the same fix as the previous commit to the last remaining
dropdownDescriptorSelector call sites in core: Security Realm, Authorization,
and Markup Formatter on hudson/security/GlobalSecurityConfiguration/index.groovy
("Manage Jenkins > Security", reachable with only Overall.SYSTEM_READ).
This was initially held back to verify it wasn't a privilege-escalation risk
before publishing: GlobalSecurityConfiguration#configure() unconditionally
calls j.checkPermission(Jenkins.ADMINISTER) as the first line, before any
submitted JSON is read, so a forged configSubmit POST from a SYSTEM_READ-only
user is rejected server-side (AccessDeniedException3) regardless of what the
UI rendered; the Save/Apply buttons are also only rendered inside
l.isAdmin(). The lazily-rendered fragment itself never carries live secrets
either, since dropdownDescriptorSelector renders non-selected options with
instance=null. Confirmed the same double gate (checkPermission(CONFIGURE) in
doConfigSubmit) exists for the other already-fixed call sites, so this is the
same severity class as the rest of the change: a read-only-mode UI/UX gap,
not a write-path vulnerability.
Adds a regression test (GlobalSecurityConfigurationReadOnlyModeTest) covering
this Groovy-view, SYSTEM_READ-scoped rendering path, following the same
pattern as SCMCheckoutStrategyReadOnlyModeTest: register a throwaway
AuthorizationStrategy with a real editable field, trigger the same
renderOnDemand() JS a browser fires when switching the dropdown, and assert
the fragment renders as the standard read-only N/A placeholder.
* Propagate readOnlyMode once in dropdownDescriptorSelector taglib, not per caller
Per jtnord's review on #27167: rather than requiring every caller of
f:dropdownDescriptorSelector to pass capture="readOnlyMode" (12 call
sites in core alone, plus any plugin using the same taglib), fix it
once in the taglib itself.
lib/form/dropdownDescriptorSelector.jelly already always captures
"descriptor" and "it" for the lazily rendered l:renderOnDemand
fragment regardless of what the caller's capture attribute lists.
readOnlyMode now joins that same always-captured set, so read-only
mode propagates into every lazily loaded descriptor fragment
ecosystem-wide without any caller changes.
This reverts the 12 per-callsite capture="readOnlyMode" additions
from the previous commits on this branch and updates the two
JenkinsRule/HtmlUnit regression tests' documentation to point at the
new, single fix location. Both tests still pass unchanged, since they
exercise the real page end-to-end rather than depending on any
caller's capture attribute.
* Add a taglib-level regression test for dropdownDescriptorSelector
The two existing regression tests on this branch (SCMCheckoutStrategy,
GlobalSecurityConfiguration) exercise real pages end-to-end through
JenkinsRule + MockAuthorizationStrategy, which only covers 2 of the
now-generic fix's many callers and requires standing up a full
permission model to prove a taglib-level behavior.
Following this project's existing convention for testing this exact
taglib family (lib/form/DropdownListTest, lib/layout/RenderOnDemandTest,
lib/form/RowVisibilityGroupTest, the latter of which already reuses a
single config.jelly across sibling Descriptor implementations), add a
lean unit test that exercises f:dropdownDescriptorSelector directly via
a synthetic RootAction, with no security realm involved. The fixture's
test1.jelly sets readOnlyMode directly and deliberately omits
capture="readOnlyMode", proving the taglib itself is responsible for
propagating it into the lazily-rendered fragment -- which by
construction covers every current and future caller, not just the two
pages exercised by the other tests.
* Empty commit to retrigger CI
* Drop support for remoting releases before 2024-08
* Adapt Security3430Test to latest changes
Uses the original changes from @daniel-beck, merged with master branch.
One relevant change for discussion is the switch from IllegalStateException
to IOException in the assertions in the _run method. I believe that is the
correct change, but would like validation from @daniel-back to be certain.
- assertThat(itex.getCause(), instanceOf(IllegalStateException.class));
+ assertThat(itex.getCause(), instanceOf(IOException.class));
Testing done:
* Confirmed Security3430Test passes in my development environment
---------
Co-authored-by: Daniel Beck <daniel-beck@users.noreply.github.com>
Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>
Remove dead .crumb fallback in CrumbFilter
The fallback added in ed0ea631 (JENKINS-12875) discarded its return
value, so the legacy .crumb field name has never been accepted since
2014. The compatibility window it targeted is long expired; delete the
dead code instead of reviving it. Add a test pinning that a valid crumb
under the configured field name is accepted and the same crumb under
".crumb" is rejected.
Fixes#27431
* Remove the -jnlpUrl deprecation warning from the JNLP file download
Since the 2.440.1 migration guidance, agents launch with -url and -name and
the remoting launcher already logs the deprecation warning when -jnlpUrl is
actually used. The remaining consumer of the JNLP file endpoint is
automation: provisioning tools download jenkins-agent.jnlp to extract the
connection secret before starting the agent. For each such download the
controller logged a warning claiming the agent is connecting with -jnlpUrl,
which is false and sends operators chasing a non-existent problem on the
agent side.
Drop the endpoint-level warning: the actual deprecated launch path warns on
its own, where the message is true.
* Reword the deprecation warning logged on JNLP file downloads
The warning claimed the agent is connecting with the -jnlpUrl argument,
but it is emitted on a plain file download with no agent connection
involved. Agents launch with -url and -name since the 2.440.1 migration
guidance, and the remoting launcher warns on its own when -jnlpUrl is
actually used.
State that the JNLP file endpoint itself is deprecated and point at the
agent documentation, keeping the signal without the misattribution.
---------
Co-authored-by: log0u7 <logout@github.com>
Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
* Use assertions in test body instead of assumptions in SlaveTest
Failed assumptions silently ignore the test
Failed assertions call us to immediate action
* Use assertEquals instead of assumeTrue in ArgumentListBuilder2Test
* Use assertFalse, not assumeFalse in UpdateCenterPluginInstallTest
Fail the tests if updates.jenkins-ci.org cannot be resolved rather than
quietly skipping the tests. If our tests need to be resilient to DNS
lookup failures, there are many other places that need to be changed.
* Assert rather than assume white listed classes include LinkedListMultimap in ClassFilterImplTest
* Remove assume that checked if tests are running in Jetty servlet context in SystemPropertiesTest
Tests always run with Jetty servlet context.
* Replace assume with assert in FilePathTest
If the assumption were not satisfied, the test would be skipped insted
of failing.
Better to fail the test explicitly than to quietly skip the test and
rely on review of the results to detect the test was skipped.
Testing done:
* Confirmed the test continues to pass
renovate[bot]