GeezerVison is showing github.com — fix(policy): judge the declared constraint, accept package release tags by Kaustubh1235 · Pull Request #3381 · microsoft/apm
Conversation
Description
require_pinned_constraint now judges the constraint the author declared, and recognises a package's own release tags.
Two things were wrong. The resolve phase rewrites a direct dependency's in-memory reference to the tag its semver range selected, and the install gate runs after that, so pkg-a#^1.0.0 was judged as pkg-a-v1.1.0. The literal-tag classifier also only knew v{version}, while the resolver selects from v{version}, {name}--v{version} and {name}-v{version} and the dependency guide tells people to pin the package-qualified forms.
The resolve phase now snapshots the manifest-declared refs of the direct dependencies before any rewrite (ctx.declared_direct_refs), and policy_gate and policy_target_check pass that map to run_dependency_policy_checks, which classifies it in place of the rewritten reference. Nothing else sees a different reference: download, drift and lockfile work keep the resolved tag, and preflight and audit already held the manifest view. The classifier accepts {name}-v{version} and {name}--v{version} for the dependency's own package name only, reusing the resolver's DEFAULT_TAG_PATTERNS and build_tag_regex, so pkg-b-v1.1.0, pkg-a-v1.1, release-pkg-a-v1.1.0 and pkg-a_v1.1.0 remain bare branches. The package name follows the resolver's rule (final virtual-path segment, else repository name), with a unit test asserting parity against _git_semver_package_name.
Docs updated where the rule is described (policy-reference.md, policy-schema.md, governance-on-the-consumer-ramp.md, manage-dependencies.md, and the REQUIRE_PINNED_CONSTRAINT_HELP text), including correcting two places that said transitive deps are classified; the check has been direct-only since #1494.
Issue and approved scope
Issue: #3224
Human scope-approval comment: #3224 (comment)
This PR completes the accepted issue scope. It does not request merge approval.
Type of change
- Bug fix
- New feature
- Documentation
- Maintenance / refactor
Testing
- Tested locally
- All existing tests pass
- Added tests for new functionality
Unit (tests/unit/policy/test_pinned_constraint_declared.py, 13 tests): package-qualified forms for subdirectory and repository deps, prerelease and build suffixes, other-package and near-miss negatives, name parity with the resolver, declared_ref precedence (a declared main stays a violation after resolution replaced it with a tag; a declared >=1.0.0 stays open-upper when the reference is a SHA), and _check_pinned_constraints with and without declared_refs.
Gate wiring (TestDeclaredRefsWiring in test_require_pinned_constraint_e2e.py): pinned to the gate's own call. Verified it fails when either the gate stops forwarding declared_refs or the resolve phase stops recording them.
Real binary (tests/integration/policy/test_require_pinned_constraint_declared_e2e.py, e2e + requires_apm_binary): one local bare monorepo with a subdirectory package tagged pkg-a-v1.1.0 / pkg-a--v1.1.0 and the root tagged v1.0.0 only, so ^1.0.0 resolves to the package-qualified tag the old gate rejected. Policy reaches install the way the Govern contract does (ADO-shaped origin, leaf extending the strict policy at the cache-key path, policy status warm), and every governed command asserts the (cached diagnostic. Covers fresh install, frozen replay, repeat install, update --yes and audit for the range; the two literal forms; the repository-level range; and main, pkg-b-v1.1.0, >=1.0.0 blocked at install and failed by audit with the same hints. Audits are judged by the dependency-pinned-constraint check in the JSON, not the exit code.
Local validation: tests/unit/policy tests/unit/install tests/integration/policy tests/integration/test_policy_pinned_constraint_e2e.py: 4360 passed, 7 skipped, 1 xfailed. tests/spec_conformance/test_policy_reqs.py passes. The real-binary contract passed on three consecutive runs. Ruff check and format clean on every changed file.
Observed while writing the contract, out of scope here and identical on unmodified main (same scenario, same binary build, byte-for-byte the same lock and deployed state at every step): on this package shape, install --frozen right after a fresh install redeploys the 1.0.0 skill while the lock still records pkg-a-v1.1.0, and a plain repeat install drops constraint and resolved_tag and writes the raw range into resolved_ref; update --yes restores them. I'll file that separately with the probe script. The contract therefore asserts the policy verdict on those steps and not what they record.
Spec conformance (OpenAPM v0.1)
- Spec edit
- Manifest edit
- Test edit
-
CONFORMANCE.{md,json}
- N/A -- this PR does not change OpenAPM-observable behaviour.
req-pl-007 flags "a bare branch name"; a dependency's own release tag in a layout the resolver selects from is a tag, not a branch, so recognising it is a classification repair under the existing rule. req-pl-008 enumerates forms that MUST count as pinned and is unchanged. If the maintainers want req-pl-008 to list the package-qualified layouts explicitly, that would be a separate spec proposal under normal review.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
require_pinned_constraint judged the wrong string in two ways.
The resolve phase rewrites a direct dependency's in-memory reference to
the tag a semver range selected, and the install gate runs after that,
so a bounded range such as `pkg-a#^1.0.0` was classified as whatever tag
it resolved to. The resolve phase now records the manifest-declared refs
of the direct dependencies before any rewrite, and the gate and the
post-targets re-check classify those. The resolved reference is left in
place for download, drift and lockfile work; preflight and audit already
hold the manifest view and are unchanged.
The literal-tag classifier only knew the `v{version}` layout, while the
resolver selects from `v{version}`, `{name}--v{version}` and
`{name}-v{version}` and the dependency guide recommends pinning the
package-qualified forms. The classifier now accepts those layouts for
the dependency's own package name, using the resolver's tag patterns and
regex builder, so `pkg-a-v1.1.0` on a `pkg-a` dependency is pinned while
`pkg-b-v1.1.0`, `pkg-a-v1.1` or `release-pkg-a-v1.1.0` stay bare
branches. Missing refs, moving branches, wildcards and open-upper ranges
are classified as before, and a selected tag or SHA never launders an
unbounded declaration.
Refs microsoft#3224.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Duplicate dependency identities can overwrite declared constraints and let a branch pass the pinned-constraint gate; package-name derivation also needs one shared owner.
2 open issues
What changed in this PR
This PR addresses #3224 by making pinned-constraint policy checks evaluate declared references rather than resolved tags, and recognize package-qualified release tags.
Changes:
- Capture direct dependency declarations and forward them to install policy checks.
- Accept release tags matching the dependency's own package name.
- Add regression coverage and clarify policy behavior in documentation.
| File |
Description |
| tests/unit/policy/test_pinned_constraint_declared.py |
Tests declared-ref precedence and package-qualified tags. |
| tests/integration/policy/test_require_pinned_constraint_e2e.py |
Checks declaration forwarding to the policy gate. |
| tests/integration/policy/test_require_pinned_constraint_declared_e2e.py |
Adds real-binary install, replay, update, and audit coverage. |
| src/apm_cli/policy/policy_checks.py |
Passes declared refs into classification and diagnostics. |
| src/apm_cli/policy/_help_text.py |
Clarifies accepted tags and declared-constraint semantics. |
| src/apm_cli/policy/_constraint_pinning.py |
Recognizes package-qualified tags and declared-ref overrides. |
| src/apm_cli/install/phases/resolve.py |
Snapshots direct refs before resolution rewrites them. |
| src/apm_cli/install/phases/policy_target_check.py |
Forwards declarations during target checks. |
| src/apm_cli/install/phases/policy_gate.py |
Forwards declarations to the install gate. |
| src/apm_cli/install/context.py |
Stores the declared-reference snapshot. |
| docs/src/content/docs/reference/policy-schema.md |
Updates policy semantics and examples. |
| docs/src/content/docs/enterprise/policy-reference.md |
Clarifies direct-only evaluation and accepted tags. |
| docs/src/content/docs/consumer/manage-dependencies.md |
Explains policy acceptance of ranges and package tags. |
| docs/src/content/docs/consumer/governance-on-the-consumer-ramp.md |
Clarifies that policy judges direct declarations. |
Review effort: Balanced
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Comment on lines
+419
to
+421
|
|
ctx.declared_direct_refs = {
|
|
|
dep.get_unique_key(): dep.reference for dep in ctx.all_apm_deps if dep.reference is not None
|
|
|
}
|
Comment on lines
+136
to
+139
|
|
virtual_path = getattr(dep, "virtual_path", None)
|
|
|
is_subdirectory = getattr(dep, "is_virtual_subdirectory", None)
|
|
|
if callable(is_subdirectory) and is_subdirectory() and virtual_path:
|
|
|
return virtual_path.rstrip("/").rsplit("/", 1)[-1] or None
|
|
Thank you for contributing this policy repair. Issue #3224 has an explicit maintainer-approved scope, and this PR appears to implement it. The requested reviewers include Daniel Meppiel (@danielmeppiel) and Sergio Sisternes (@sergio-sisternes-epam). The license/cla check is currently queued. This is a recommendation for human review only, not merge approval.
Generated by autopilot-pr-triage-worker. This comment is AI-generated and may contain errors.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Kaustubh Arora (@Kaustubh1235) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]
Options:
- (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
@microsoft-github-policy-service agree
- (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.
@microsoft-github-policy-service agree company="Microsoft"
Contributor License Agreement
Contribution License Agreement
This Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
and conveys certain license rights to Microsoft Corporation and its affiliates (“Microsoft”) for Your
contributions to Microsoft open source projects. This Agreement is effective as of the latest signature
date below.
- Definitions.
“Code” means the computer software code, whether in human-readable or machine-executable form,
that is delivered by You to Microsoft under this Agreement.
“Project” means any of the projects owned or managed by Microsoft and offered under a license
approved by the Open Source Initiative (www.opensource.org).
“Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
Project, including but not limited to communication on electronic mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
discussing and improving that Project, but excluding communication that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material Submitted by You, including any
associated comments and documentation.
- Your Submission. You must agree to the terms of this Agreement before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now or in the future (except as
described in Section 4 below), Submit to any Project.
- Originality of Work. You represent that each of Your Submissions is entirely Your original work.
Should You wish to Submit materials that are not Your original work, You may Submit them separately
to the Project if You (a) retain all copyright and license information that was in the materials as You
received them, (b) in the description accompanying Your Submission, include the phrase “Submission
containing materials of a third party:” followed by the names of the third party and any licenses or other
restrictions of which You are aware, and (c) follow any other instructions in the Project’s written
guidelines concerning Submissions.
- Your Employer. References to “employer” in this Agreement include Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your employer has intellectual
property rights in Your Submission by contract or applicable law, You must secure permission from Your
employer to make the Submission before signing this Agreement. In that case, the term “You” in this
Agreement will refer to You and the employer collectively. If You change employers in the future and
desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
and secure permission from the new employer before Submitting those Submissions.
- Licenses.
- Copyright License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
parties.
- Patent License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under
Your patent claims that are necessarily infringed by the Submission or the combination of the
Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the Project.
- Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.
- Representations and Warranties. You represent that You are legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
have disclosed under Section 3). You represent that You have secured permission from Your employer to
make the Submission in cases where Your Submission is made in the course of Your work for Your
employer or Your employer has intellectual property rights in Your Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
- Notice to Microsoft. You agree to notify Microsoft in writing of any facts or circumstances of which
You later become aware that would make Your representations in this Agreement inaccurate in any
respect.
- Information about Submissions. You agree that contributions to Projects and information about
contributions may be maintained indefinitely and disclosed publicly, including Your name and other
information that You submit with Your Submission.
- Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and
the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County,
Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to
exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all
defenses of lack of personal jurisdiction and forum non-conveniens.
- Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
supersedes any and all prior agreements, understandings or communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may be assigned by Microsoft.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Hi Kaustubh Arora (@Kaustubh1235), thanks for this fix for #3224. The scope has been accepted, so the next step is on the Contributor License Agreement: CI cannot run on this PR until the CLA is signed. Please follow the instructions in the CLA comment above (reply with @microsoft-github-policy-service agree, adding company="..." if you are contributing on behalf of an employer). Once that is done the checks will start and we can continue with the review.
Generated by autopilot-pr-ready-worker. This comment is AI-generated and may contain errors.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This branch has not been deployed
No deployments
Reviewers
At least 0 approving reviews are required to merge this pull request.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Labels
area/audit-policy
apm-policy.yml schema, custom_checks, install-time enforcement.
status/accepted
Human scope approval; verify the issue's approval record and review contact before work.
triage/recommended
Automated advice completed; not human scope approval.
type/bug
Something does not work as documented.
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
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.
|
