Fix all tests - #559
Draft
bastelfreak wants to merge 3 commits into
Draft
Conversation
include_system_store requests from the server (report processors posting to external HTTPS endpoints, and any Puppet.runtime[:http] caller passing the option) stopped trusting publicly-signed certificates in the 9.0.0 betas, failing with PKIX path building errors. This is what broke acceptance/suites/tests/https/client_may_use_external_cert_chains.rb on all platforms in acceptance run 31098859281. Root cause: Puppet::Server::Config.load_puppet_and_system_ssl_context builds the system trust by merging a vendored Java keystore from /opt/puppetlabs/puppet/ssl/puppet-cacerts, and puppet-runtime deliberately stopped shipping that keystore for the 9.x agent (puppet-runtime@066fd48, on the reasonable suspicion it was an unused PE-era artifact -- OpenVox does not package Java). The server was its one consumer; with the file absent the context silently degrades to puppet-CA-only trust with a single warning. Fall back to the PEM CA bundle the runtime still ships at /opt/puppetlabs/puppet/ssl/cert.pem, loaded through the same SSLUtils reader already used for the ssl_trust_store setting. The keystore is still preferred when present, so 8.x-era agents are unaffected. Trust content is identical either way (both forms are generated from the same Mozilla bundle). Verified against openvox-server 9.0.0~beta4 with the 9.0.0~beta2 agent on a local beaker rig: the isolated reproduction (puppetserver ruby fetching https://voxpupuli.org with include_system_store: true) fails with PKIX before and returns 200 after, and the full client_may_use_external_cert_chains.rb acceptance test passes with the patched jar. Longer term this pairs with openvox#554 (stop bundling CA certificates): when that lands, this method should grow a further fallback to the system trust anchors. This change keeps 9.0 compatible with the trust behavior 8.x shipped. Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The report/notme step asserted that the primary may submit reports on behalf of other nodes when master.is_pe? is true. This suite's beaker options do not set a host type, and beaker's default type is 'pe', so is_pe? returned true on every FOSS host and selected the PE assertion -- which the shipped allow: "$1" report rule correctly rejects with 403. This is the step where default_rules.rb actually failed in acceptance run 31098859281, before the filebucket assertions were ever reached. OpenVox has no PE edition, so drop the PE arm and assert the denial unconditionally, with a comment warning against reintroducing is_pe? guards while the suite's host type is unset. Verified on a local beaker rig against openvox-server 9.0.0~beta4: the unmodified test fails at report/notme exactly as in the pipeline; with this commit plus the filebucket fix already on this branch, default_rules.rb passes end to end (including the new agent-cert filebucket denial and primary-cert 404 assertions). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com>
The filebucket check in default_rules.rb asserted that an authenticated
request is refused a read, but curl_authenticated uses the primary's own
certificate, and that certificate carries the pp_cli_auth extension so
that the primary's CLI tooling can reach administrative endpoints:
1.3.6.1.4.1.34380.1.3.39:
..true
The auth.conf rule gates reads on exactly that extension, so the request
is allowed by design and the assertion could never pass. It failed on
every platform.
Assert instead that the primary's certificate is allowed through to the
endpoint, and generate an agent certificate, which does not carry the
extension, to cover the case the rule is meant to refuse. Also check that
the agent certificate may still issue 'head', so that the store path
stays open to agents while reads are restricted.
Verified against openvox-server 9.0.0~beta4 on el9:
primary cert HEAD -> 404 agent cert HEAD -> 404
primary cert GET -> 404 agent cert GET -> 403
no client cert GET -> 403
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com>
Contributor
|
The rpm/deb packages and the JAR file for openvox-server are available in a zip archive: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a combination of:
related acceptance tests: https://github.com/OpenVoxProject/acceptance-pipelines/actions/runs/31157133263