feat(api): refuse downloads until host-side decryption exists - #3
Conversation
extract_links used to hand the host a raw CDN URL whose bytes are AES-128-CTR ciphertext; the host contract ignores the encryption metadata, so MEGA links downloaded 'successfully' as unreadable files. Both download-facing exports now return an explicit DecryptionNotSupported error. Resolution and crypto code stays in the library, ready to rewire once Vortex can decrypt during download (MAT-136 R-04).
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
📝 WalkthroughWalkthroughThe plugin now validates supported MEGA URLs and refuses link extraction and stream resolution because decryption is unavailable. It adds a dedicated error, removes HTTP resolution wiring, updates documentation and tests, and bumps crate and plugin versions to 1.1.0. ChangesMEGA decryption refusal
Estimated code review effort: 3 (Moderate) | ~15 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Cargo.toml`:
- Line 3: Update the package version in Cargo.toml from 1.1.0 to 2.0.0, and
update the corresponding version field in plugin.toml to 2.0.0 so both version
files remain aligned.
In `@plugin.toml`:
- Line 3: Update the manifest capability description near version 1.1.0 to
remove claims of URL resolution and AES-128-CTR streaming decryption. Describe
recognition and playlist support, and explicitly state that downloads are
unavailable until host-side decryption is implemented.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a33957a1-27b1-42f3-b4c3-e1f1f2e7c547
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
Cargo.tomlplugin.tomlsrc/error.rssrc/lib.rssrc/plugin_api.rs
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
cubic analysis
2 issues found across 6 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="plugin.toml">
<violation number="1" location="plugin.toml:3">
P2: The 1.1.0 manifest still advertises host-usable AES-128-CTR decryption even though MEGA downloads now fail with `DecryptionNotSupported`, so the catalog can present this hoster as downloadable when it is not. According to linked Linear issue MAT-136 (R-04), the manifest should describe MEGA downloads as unavailable until host-side decryption exists.</violation>
</file>
<file name="src/lib.rs">
<violation number="1" location="src/lib.rs:6">
P2: According to linked Linear issue MAT-136 (R-04), unavailable MEGA downloads must be presented honestly; this new contract is not propagated to the README or WASM smoke test, leaving users with the old capability description and CI with assertions for the superseded behavior. Updating the contract documentation and test expectations alongside this change would keep the release surface consistent.</violation>
</file>
Linked issue analysis
Linked issue: MAT-136: [Lot 3] Aligner l’interface et le catalogue sur les capacités réelles
| Status | Acceptance criteria | Notes |
|---|---|---|
| ✅ | R-04 — MEGA and 1fichier must not produce a fake successful download of encrypted data or an HTML page. | The PR changes the download-facing exports to refuse with a clear DecryptionNotSupported error, adds the error variant and a unit test for the message, and leaves link recognition unchanged so UI can show honest errors. |
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| //! - `supports_playlist(url)` → `"true"` for folder URLs, `"false"` otherwise | ||
| //! - `extract_links(url)` → JSON metadata for a single MEGA file | ||
| //! - `resolve_stream_url(input)` → encrypted CDN URL (host fetches + decrypts) | ||
| //! - `extract_links(url)` / `resolve_stream_url(input)` → refused with an |
There was a problem hiding this comment.
P2: According to linked Linear issue MAT-136 (R-04), unavailable MEGA downloads must be presented honestly; this new contract is not propagated to the README or WASM smoke test, leaving users with the old capability description and CI with assertions for the superseded behavior. Updating the contract documentation and test expectations alongside this change would keep the release surface consistent.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/lib.rs, line 6:
<comment>According to linked Linear issue MAT-136 (R-04), unavailable MEGA downloads must be presented honestly; this new contract is not propagated to the README or WASM smoke test, leaving users with the old capability description and CI with assertions for the superseded behavior. Updating the contract documentation and test expectations alongside this change would keep the release surface consistent.</comment>
<file context>
@@ -3,8 +3,8 @@
//! - `supports_playlist(url)` → `"true"` for folder URLs, `"false"` otherwise
-//! - `extract_links(url)` → JSON metadata for a single MEGA file
-//! - `resolve_stream_url(input)` → encrypted CDN URL (host fetches + decrypts)
+//! - `extract_links(url)` / `resolve_stream_url(input)` → refused with an
+//! explicit error until the host can decrypt MEGA payloads (MAT-136 R-04)
//!
</file context>
There was a problem hiding this comment.
Valid — CI was red on exactly this: folder_e2e and the wasm_smoke extraction test still asserted the old contract. Fixed in 650b0c6: the README contract table and status now describe the refusal, wasm_smoke asserts both exports refuse a valid file URL, and folder_e2e is slimmed to a wasm-boundary check that folder URLs refuse too (the synthetic decryption fixture stays in git history for the rewire).
|
v1.1.0 is tagged and released. The CI-built wasm hashes |
1 participant
Part of MAT-136 (R-04): MEGA can't produce fake successful downloads of encrypted data.
MEGA CDN bytes are AES-128-CTR ciphertext and the Vortex host has no decryption pipeline yet, so a "successful" download would write unreadable bytes to disk. The host's hoster contract also requires
direct_urland drops encryption metadata, so returning the CDN URL fromextract_linksleaves the ciphertext path open even ifresolve_stream_urlrefuses.What changed
extract_linksandresolve_stream_urlnow validate the URL, then refuse withPluginError::DecryptionNotSupported("MEGA downloads are not supported yet: files are end-to-end encrypted...").can_handleandsupports_playliststill work, so link recognition and honest error surfacing in the UI are unchanged.After merge
Tag v1.1.0 and publish the GitHub release with the exact built artifacts. The vortex registry PR (feat/mat-136-align-capabilities) already carries their checksums:
vortex_mod_mega.wasmsha256c846257ab043b4863c359f6e6385c9af598e2cd3b27eab0ecc2b957f51abbe52plugin.tomlsha256330d8c9540b1018c9ad1d13385dbaab0f9ab625fc055fc383d32b83e213d3392Tests
68 tests pass, clippy clean, wasm32-wasip1 release builds.
Summary by CodeRabbit
extract_linksandresolve_stream_urlnow fail with a “not supported yet” decryption error instead of returning metadata/URLs.