.NET, Python: Reject file skills with resource or script names that differ only by case - #10158

MAF Automated Review — Iteration 1

Result: Findings reported
Scope: full PR (2 commit(s)): 13ca088fc4da, 6424dc69593d
Model: gpt-5.6-sol

Overview

The PR adds local case-insensitive collision checks and preserves unrelated skills when one skill is rejected, with focused filesystem and archive tests around the intended behavior. The guards correctly separate resource and script namespaces and retain existing archive size and traversal protections. Two archive paths remain inconsistent: Python does not reject case-variant manifests, and .NET cannot observe case-colliding archive resources after Windows extraction has already deduplicated them.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
2 verified findings remained after source verification (2 medium) across 2 files. Details are attached to the affected lines below.

Affected areas: dotnet/src/Microsoft.Agents.AI/Skills/File/AgentFileSkillsSource.cs, python/packages/core/agent_framework/_skills.py

MAF Automated Review — Iteration 2

Result: No findings
Scope: 3 net-new commit(s): b2642200eb4e, c9c47e5e4813, 7865be586a6a
Model: gpt-5.6-sol

Overview

The incremental changes reject case-variant archive destinations in .NET on every operating system and reject case-variant Python manifest paths before selecting a manifest. The strongest guardrails are order-independent collision tests, per-skill failure isolation, .NET partial-extraction cleanup, and preservation of first-entry behavior for exact normalized .NET aliases. No Critical, High, or Medium defect introduced by the authoritative incremental range remained after reconciliation.

Reviewed the supplied incremental change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

The new Python and .NET checks still disagree for valid non-ASCII resource names. At head 7865be586a6a9d0bb732f3bcb8c87eb3e75a83f5, Python's FileSkill._reject_case_variant_names keys names with str.lower(), while .NET's HasCaseVariantNames uses StringComparer.OrdinalIgnoreCase.

For example, resources named Σ.md (U+03A3) and ς.md (U+03C2) are both accepted by the current Python FileSkill constructor. Their lowercase keys are σ.md and ς.md. On installed .NET 10.0.10, the actual comparer used by the C# check considers these names equal:

StringComparer.OrdinalIgnoreCase.Equals("\u03A3.md", "\u03C2.md") // True

Python's resource lookup has the corresponding difference: a skill containing only ς.md returns None for await skill.get_resource("Σ.MD"), whereas that name pair compares equal with .NET 10's comparer.

I reproduced the Python behavior using the unchanged complete FileSkill, Skill, SkillFrontmatter, SkillResource, and InlineSkillResource definitions and their validation helpers from this head, exercising the public constructor, get_resource, and read. The .NET comparison ran separately under System.Private.CoreLib 10.0.0.0 / runtime 10.0.10. Controls: readme.md/README.md was rejected by Python and compared equal in .NET; one.md/two.md was accepted and compared unequal; straße.md/strasse.md was accepted and compared unequal. Thus replacing lower() with unrestricted casefold() is not an exact match for the .NET semantics either.

Could the intended comparison contract be made explicit and covered with a non-ASCII regression case? If the goal is the same accepted names across the two SDKs, both implementations need a shared comparison rule. If only ASCII case variants are in scope, documenting that boundary would avoid promising broader consistency.

Scope: this is a constructor/comparer consistency finding, not an end-to-end archive, filesystem-discovery, MCP, or security finding. I did not run the full Python or .NET owner suites. The installed .NET Framework 4.8 comparer returned unequal for the sigma pair, so the result above specifically concerns the tested .NET 10 target; it is not a claim about every supported runtime.

AI assistance: Codex assisted with the analysis, isolated reproduction, and this review.