fix(byteport): remove dead code, tighten security, prune unused deps (bp-001..039)#217
Conversation
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
the
size:L
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request cleans up the frontend/web/src-tauri crate by removing an abandoned AWS-SDK transport stack, deleting several dead-code files, and pruning unused dependencies. It also wires the live S3UploadTransport into Tauri's shared state, registers the create_upload IPC handler, and hardens the application's security configuration in tauri.conf.json. Feedback on these changes highlights a potential IPC block on Windows due to an incorrect protocol scheme in devCsp, duplicated terminal logging from dual logger initializations, and a deprecated Tauri 1.x updater configuration block that should be removed.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| } | ||
| "security": { | ||
| "csp": "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; connect-src 'self' ipc: https://ipc.localhost https://api.byteport.dev; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self';", | ||
| "devCsp": "default-src 'self' http://localhost:5173 ws://localhost:5173; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; connect-src 'self' ipc: http://ipc.localhost https://api.byteport.dev ws://localhost:5173;", |
There was a problem hiding this comment.
In devCsp, the connect-src directive specifies http://ipc.localhost instead of https://ipc.localhost. In Tauri 2.x, the IPC protocol on Windows uses https://ipc.localhost. Using http:// here will cause IPC requests to be blocked by the Content Security Policy in development mode on Windows. It should be updated to https://ipc.localhost to match the production csp configuration.
| "devCsp": "default-src 'self' http://localhost:5173 ws://localhost:5173; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; connect-src 'self' ipc: http://ipc.localhost https://api.byteport.dev ws://localhost:5173;", | |
| "devCsp": "default-src 'self' http://localhost:5173 ws://localhost:5173; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; connect-src 'self' ipc: https://ipc.localhost https://api.byteport.dev ws://localhost:5173;", |
| let _ = tracing_subscriber::fmt() | ||
| .with_env_filter( | ||
| tracing_subscriber::EnvFilter::try_from_default_env() | ||
| .unwrap_or_else(|_| tracing_subscriber::EnvFilter::new("info")), | ||
| ) | ||
| .with_target(true) | ||
| .try_init(); |
There was a problem hiding this comment.
Initializing both tracing_subscriber::fmt (which writes to stdout/stderr by default) and tauri-plugin-log (which also writes to stdout/stderr by default) will result in duplicated log outputs in the terminal. To avoid duplicate logs and potential conflicts over the global logger, consider relying solely on tauri-plugin-log for all logging (as it can be configured with stdout/stderr targets), or disable the stdout/stderr targets in tauri-plugin-log if you prefer tracing-subscriber for terminal output.
| "createUpdaterArtifacts": true, | ||
| "updater": { | ||
| "active": true, | ||
| "endpoints": ["https://releases.byteport.dev/byteport/{{target}}/{{arch}}/{{current_version}}"], | ||
| "dialog": true, | ||
| "pubkey": "REPLACE_WITH_RELEASE_SIGNING_PUBKEY" | ||
| } |
There was a problem hiding this comment.
In Tauri 2.x, the updater configuration has been moved entirely to the plugins.updater section (which is already correctly configured on lines 79-85). The bundle.updater configuration is a leftover from Tauri 1.x and is deprecated/invalid, which can cause schema validation warnings or errors. You should remove it from the bundle section.
"createUpdaterArtifacts": true![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| fn upload_endpoint() -> String { | ||
| std::env::var("BYTEPORT_UPLOAD_URL") | ||
| .unwrap_or_else(|_| "https://uploads.byteport.local".to_string()) | ||
| } |
There was a problem hiding this comment.
Suggestion: BYTEPORT_UPLOAD_URL is accepted as-is, including an empty string. If the variable is set but empty, S3UploadTransport receives an empty endpoint and produces malformed relative upload URLs at runtime. Treat empty/whitespace values as missing and fall back to the default endpoint. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Desktop uploads break when endpoint env is misconfigured.
- ⚠️ Upload IPC returns unusable pre-signed URLs to frontend.Steps of Reproduction ✅
1. Configure the environment so `BYTEPORT_UPLOAD_URL` is present but empty (e.g.
`BYTEPORT_UPLOAD_URL=` in a shell), then start the desktop app which calls `run()` in
`frontend/web/src-tauri/src/lib.rs:40-84`.
2. During startup, `run()` calls `upload_endpoint()` at `lib.rs:53-55`, which in turn
executes `std::env::var("BYTEPORT_UPLOAD_URL")` at `lib.rs:29`; because the variable
exists, `std::env::var` returns `Ok(String::from(""))` and the `unwrap_or_else` fallback
at `lib.rs:30` is not used.
3. `upload_endpoint()` therefore returns an empty string, and
`S3UploadTransport::new(upload_endpoint(), upload_bucket(), Some("desktop"))` at
`lib.rs:53-57` receives an empty endpoint string while the bucket is populated.
4. When the frontend invokes the Tauri command `ipc::create_upload` at `lib.rs:121-140` to
get upload instructions, the underlying `UploadTransport` instance uses the empty endpoint
configured at startup, resulting in malformed or hostless upload URLs instead of falling
back to the default `"https://uploads.byteport.local"` endpoint.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** frontend/web/src-tauri/src/lib.rs
**Line:** 28:31
**Comment:**
*Incorrect Condition Logic: `BYTEPORT_UPLOAD_URL` is accepted as-is, including an empty string. If the variable is set but empty, `S3UploadTransport` receives an empty endpoint and produces malformed relative upload URLs at runtime. Treat empty/whitespace values as missing and fall back to the default endpoint.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| fn upload_bucket() -> String { | ||
| std::env::var("BYTEPORT_UPLOAD_BUCKET") | ||
| .unwrap_or_else(|_| "byteport-uploads".to_string()) | ||
| } |
There was a problem hiding this comment.
Suggestion: BYTEPORT_UPLOAD_BUCKET is used without checking for empty content. If this env var is present but empty, generated upload URLs contain an empty bucket segment (e.g. double slash path), causing upload routing failures. Treat empty/whitespace bucket values as invalid and use the fallback bucket. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Desktop uploads fail with misconfigured empty bucket name.
- ⚠️ Upload IPC returns URLs with invalid bucket segment.Steps of Reproduction ✅
1. Configure the environment so `BYTEPORT_UPLOAD_BUCKET` is present but empty (e.g.
`BYTEPORT_UPLOAD_BUCKET=`), then start the desktop app, invoking `run()` in
`frontend/web/src-tauri/src/lib.rs:40-84`.
2. During startup, `run()` calls `upload_bucket()` at `lib.rs:54-56`, which executes
`std::env::var("BYTEPORT_UPLOAD_BUCKET")` at `lib.rs:36`; because the variable exists,
`std::env::var` returns `Ok(String::from(""))` and the `unwrap_or_else` fallback at
`lib.rs:37` is not used.
3. `upload_bucket()` therefore returns an empty string, and
`S3UploadTransport::new(upload_endpoint(), upload_bucket(), Some("desktop"))` at
`lib.rs:53-57` receives an empty bucket name while the endpoint string is non-empty.
4. When the frontend calls the Tauri command `ipc::create_upload` at `lib.rs:121-140`, the
configured `UploadTransport` composes upload destinations using the empty bucket,
producing malformed upload paths or routing errors instead of defaulting to the
`"byteport-uploads"` bucket.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** frontend/web/src-tauri/src/lib.rs
**Line:** 35:38
**Comment:**
*Incorrect Condition Logic: `BYTEPORT_UPLOAD_BUCKET` is used without checking for empty content. If this env var is present but empty, generated upload URLs contain an empty bucket segment (e.g. double slash path), causing upload routing failures. Treat empty/whitespace bucket values as invalid and use the fallback bucket.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
| uploader: Arc::clone(&uploader), | ||
| }); | ||
|
|
||
| if cfg!(debug_assertions) { |
There was a problem hiding this comment.
Suggestion: The log plugin is registered twice in debug builds: once on the builder and again inside setup. Tauri plugins are identified by name, so re-registering the same plugin can return an error and abort app startup in debug mode. Keep a single tauri-plugin-log registration and configure its targets in that one instance. [api mismatch]
Severity Level: Critical 🚨
- ❌ Debug desktop app fails to start entirely.
- ⚠️ Developers lose in-app console logging during debug.Steps of Reproduction ✅
1. Build and run the desktop app in debug mode so `cfg!(debug_assertions)` evaluates to
true, invoking `run()` in `frontend/web/src-tauri/src/lib.rs:40-84`.
2. Observe that `tauri::Builder::default()` at `lib.rs:59` registers `tauri-plugin-log`
once via `.plugin(tauri_plugin_log::Builder::default().level(...).build())`.
3. Inside the `.setup` closure at `lib.rs:63-80`, in debug builds the `if
cfg!(debug_assertions)` block at `lib.rs:69-78` calls
`app.handle().plugin(tauri_plugin_log::Builder::default().level(...).build())?;`,
attempting to register the same `tauri-plugin-log` plugin a second time.
4. When the plugin system rejects the duplicate plugin (same plugin name) and returns an
error, the `?` at `lib.rs:73-77` propagates the error out of `setup`, causing
`.run(tauri::generate_context!())` at `lib.rs:81-83` to return `Err` and `expect("error
while running tauri application")` to panic, preventing the app from starting in debug
builds.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** frontend/web/src-tauri/src/lib.rs
**Line:** 69:77
**Comment:**
*Api Mismatch: The log plugin is registered twice in debug builds: once on the builder and again inside `setup`. Tauri plugins are identified by name, so re-registering the same plugin can return an error and abort app startup in debug mode. Keep a single `tauri-plugin-log` registration and configure its targets in that one instance.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
1 participant
User description
Summary
Remove 445 lines of dead code from the
frontend/web/src-tauricrate (orphanedadapters/s3.rs,ports/mod.rs,ipc.rs,network.rsthat nothing imports), prune 8 unusedCargo.tomldependencies (verified bycargo-machete+ grep), tighten thetauri.conf.jsonassetProtocol.scopefrom["**"]to 4 explicit APPDATA paths, and harden the security header set with Permissions-Policy, COOP/COEP/CORP, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy.Context
The Tauri 2.x crate had grown two parallel transport stacks:
byteport_transport::S3UploadTransport(a lightweight pure-Rust S3 presigner incrates/byteport-transport)frontend/web/src-tauri/src/adapters/s3.rs+ports/mod.rs+network.rsthat definedS3UploadTransport::new(client, bucket), aTransporttrait, amockall-basedNetworkClient, and acrate::portsmodule that nothing importsThe abandoned stack pulled in
aws-sdk-s3,tokio,tracing,async-trait,thiserror,url,tauri-plugin-os, andmockall(dev) — every one confirmed dead bycargo-macheteand a targetedrg "use tracing::"over the livesrc/tree.The security posture had three concrete gaps:
tauri.conf.jsonused the defaultcom.tauri.devidentifier (no project identity)assetProtocol.scopewas["**"]— a Tauri webview could read any file on disk viaconvertFileSrcPermissions-Policy, no COOP/COEP/CORP, no HSTS, no X-Frame-Options, no X-Content-Type-Options, no Referrer-PolicyThis was identified in the 2026-06-22 compute/infra audit (
plans/2026-06-22-compute-infra-dag-v1.md, units BP-001..013 + BP-020..029 + BP-030..039).Changes
Dead code removal
frontend/web/src-tauri/src/ipc.rs(48 lines) — top-level file that was shadowed by the inlinepub mod ipc {}inlib.rs. The benchbenches/ipc.rsimportsapp_lib::ipc::IpcEnvelopewhich resolves to the inline module, not the top-level file.frontend/web/src-tauri/src/network.rs(78 lines) —mockall::automock!-basedNetworkClientwith zero call sitesfrontend/web/src-tauri/src/adapters/s3.rs(218 lines) +adapters/mod.rs— abandoned AWS-SDK-based S3 transportfrontend/web/src-tauri/src/ports/mod.rs(45 lines) — orphanTransporttrait +Box<dyn UploadTransport>typedefDependency pruning (validated by
cargo-machete+ grep)aws-sdk-s3— dead (the live transport isbyteport-transport)tokio— dead at thesrc-taurilevel (the inlineipcis sync;byteport-transporthas its own minimaltokiosurface)tracing— dead (onlytracing_subscriberis used)async-trait,thiserror,url— dead (only used by the deleted files)tauri-plugin-os— dead (nouse tauri_plugin_osin the live source)mockall(dev) — dead (only used by the deletednetwork.rstests)logis kept (used bytauri-plugin-log'sBuilderpattern)tauri.conf.jsonhardeningidentifier:com.tauri.dev→com.byteport.desktopapp.windows[0].security.csp: preserved (strict + dev variants)app.security.assetProtocol.scope:["**"]→["$APPDATA/byteport/**", "$APPDATA/com.byteport.desktop/**", "$APPLOCALDATA/byteport/**", "$APPLOCALDATA/com.byteport.desktop/**"]app.security.headers: addedPermissions-Policy,Cross-Origin-Opener-Policy,Cross-Origin-Embedder-Policy,Cross-Origin-Resource-Policy,Strict-Transport-Security,X-Frame-Options,X-Content-Type-Options,Referrer-Policylib.rsimprovementstauri-plugin-logas a top-level plugin (was only registered in debug mode)Vendor tree
vendor/aws-runtimeis kept (it's a future drop-in for when AWS SDK is reintroduced). Its optionalhttp-1x/http-body-1xdead-feature warnings are non-actionable — they're gated by thehttp-1xfeature flag, the standard AWS SDK pattern.Use Cases
src-tauriCargo.tomlmeans a smallercargo checkgraph and faster CITesting
Links
plans/2026-06-22-compute-infra-dag-v1.md(units BP-001..013, BP-020..029, BP-030..039)phenotype-registry/docs/adrs/ADR-ECO-020-byteport-hygiene-security.mdphenotype-infra/worklog/2026-06-23-71-pillar-scorecard.mdphenotype-registry/docs/compute-infra-subtree.mdphenotype-infra(b53bbe3, 134e8de, 3fc0e1f),nanovms(fb44633, 5307653, dd7e7b0),PhenoCompose(aebf3be),phenotype-registry(735bba5)Files Changed
CodeAnt-AI Description
Harden the desktop app, clean up unused upload code, and wire in the current upload flow
What Changed
Impact
✅ Safer local file access✅ Fewer attack paths in the desktop app✅ Clearer desktop release and update behavior💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.