This repository was archived by the owner on Aug 27, 2026. It is now read-only.
Repository navigation
[Java.Interop.Tools.Maven] Assert resolved cache paths stay under CacheDirectory - #1480
Merged
Merged
Conversation
…heDirectory Adds a path-staying-under-CacheDirectory assertion to `CachedMavenRepository`. Exposes a new public API, `GetArtifactFilePath (Artifact, string)`, that returns the on-disk path where an artifact + filename would be cached and throws `InvalidOperationException` if the resolved path would not be under `CacheDirectory`. `TryGetFile`, `TryGetFilePath`, and `GetFilePathAsync` all route through this single method so there is exactly one place that knows the cache layout. The new public API lets callers (such as dotnet/android's `MavenExtensions.DownloadPayload`) stop reconstructing the cache path themselves with their own `Path.Combine` logic and get the assertion for free. Defense-in-depth, hardening. Not security enforcement. Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
Pull request overview
This PR hardens Java.Interop.Tools.Maven’s caching layer by centralizing cache path resolution in CachedMavenRepository.GetArtifactFilePath (Artifact, string) and asserting that resolved artifact paths remain under CacheDirectory (throwing InvalidOperationException on escape attempts). This supports defense-in-depth and helps external callers avoid re-implementing cache layout logic.
Changes:
- Added
CachedMavenRepository.GetArtifactFilePath (Artifact, string)and routed existing file/path retrieval APIs through it. - Added guard logic to detect resolved cache paths escaping
CacheDirectory. - Added a new NUnit test suite validating expected cache layout and escape-path failure behavior across multiple entry points.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/Java.Interop.Tools.Maven-Tests/CachedMavenRepositoryTests.cs | New tests covering cache layout and escape-path exceptions (including ensuring inner repo isn’t consulted on invalid paths). |
| src/Java.Interop.Tools.Maven/Repositories/CachedMavenRepository.cs | Introduces centralized cache path resolver with “must stay under CacheDirectory” assertion; updates existing APIs to use it. |
jonathanpeppers
added
the
ready-to-review
simonrozsival
approved these changes
Jun 23, 2026
Member
|
Oh no, I'm going to be one of those "well, actually!" people... This does not qualify as a defense-in-depth change, as it is not attempting to provide any type of protection against a trusted operator being abused into performing a malicious action. It is strictly a correctness "not security enforcement" change, per Jonathan's upthread comment. (Any attack vector here assumes a hostile operator, which defense-in-depth changes cannot meaningfully counter.) I'm just entering this into the record so that people don't misread the intent and don't go through the security reporting channels if there's a bug here. |
This was referenced Aug 20, 2026
jonathanpeppers
added a commit
that referenced
this pull request
Aug 21, 2026
…1498) Supersedes #1495 with the complete release-applicable Maven backport as exactly one commit on top of the Java.Interop commit pinned by dotnet/android `release/10.0.1xx` (`33992194b9373e9322244612c94ed9941b9bc2fd`). Backports: - #1480: assert resolved Maven cache paths remain under `CacheDirectory` - #1479: validate Maven artifact coordinates - Route Maven integration-test resolvers through `dotnet-public-maven` - Remove java-source-utils' project-local `mavenCentral()` and use Android's shared approved repository settings when embedded, with an equivalent standalone Java.Interop fallback - Coupled Maven hardening tests The Kotlin Gradle fixture from Android main is intentionally excluded because it does not exist at this release pin. Validation: - Java.Interop.Tools.Maven tests: 106 passed, 0 failed - java-source-utils assembly: succeeded - java-source-utils standalone CI-mode settings evaluation: succeeded - Fresh-cache java-source-utils `compileJava`: succeeded entirely through `dotnet-public-maven` - java-source-utils legacy suite: 16 passed before two existing missing-resource NPEs (`JavaType.java`) unrelated to repository routing Feed prerequisite: the release JavaParser `3.18.0` dependency graph must be mirrored into `dotnet-public-maven` for anonymous CI resolution. The complete graph has been seeded and fresh-cache resolution is confirmed. Co-authored-by: Copilot App <[email protected]>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Adds a path-staying-under-CacheDirectory assertion to
CachedMavenRepository. Exposes a new public API,GetArtifactFilePath (Artifact, string), that returns the on-diskpath where an artifact + filename would be cached and throws
InvalidOperationExceptionif the resolved path would not beunder
CacheDirectory.TryGetFile,TryGetFilePath, andGetFilePathAsyncall route through this single method so thereis exactly one place that knows the cache layout.
The new public API lets callers (such as dotnet/android's
MavenExtensions.DownloadPayload) stop reconstructing the cachepath themselves with their own
Path.Combinelogic and get theassertion for free.
Not security enforcement.