onionshare - Moses Yebei

The Problem

The OnionShare deployment contains a Python-based desktop application with 500 files and a CLI (56 files). The static analysis covered 90 of 90 code files (7 Shell, 75 Python, 8 JavaScript) and identified 79 findings, 23 of which are high severity. The analysis revealed 83 internal modules, 111 import edges, 23 modules in circular dependencies, and 861 named functions and 118 classes.

What This Does

The repository contains three logical sub-projects (desktop, cli, flatpak) with overlapping dependency files and duplicated code blocks. Analysis found 79 findings (30 high, 49 medium, 0 low) including 23 modules in circular import cycles affecting desktop/onionshare/__init__.py, gui_common.py, widgets.py. The asset scope includes 83 internal modules, 111 import edges, 3 modules in circular dependencies, and 861 named functions. The asset scope includes 111 import edges, 23 modules in circular dependencies, 861 named functions, and 118 classes.

What It Is

The OnionShare tool enables secure file sharing, website hosting, and chat over the Tor network. The repo contains 1252 files total across desktop/, cli/, flatpak/, docs/ directories. Primary package manager is poetry with GitHub Actions CI/CD. Notable structure: docs/ (655 files), desktop/ (500 files), cli/ (56 files), flatpak/ (13 files). Contains 20 test files and 670 doc files.

Code Health & Issues

MEDIUM - Declare least-privilege permissions for GITHUB_TOKEN in .github/workflows/build.yml (3 workflows have no permissions)
MEDIUM - Enable Dependabot or Renovate (3 manifests, no update bot configured)
MEDIUM - Gate pull requests on dependency vulnerability scan (no dependency scan in CI)
MEDIUM - Set persist-credentials: false on checkout in .github/workflows/build.yml
LOW - Set timeout-minutes on workflow jobs (3 jobs have no timeout)

The analysis confirmed 23 modules in circular dependencies affecting desktop/onionshare/__init__.py, gui_common.py, and widgets.py. 18 files show deep nesting making control flow hard to follow. 14 files have broad exception handling that swallows errors indiscriminately. One file desktop/onionshare/tab/mode/history.py contains 677 code lines making it hard to hold in one head. 193 repeated 6-line blocks exist across 55 files.

The Bottom Line

The repository has measurable structural issues: circular imports in core desktop modules, oversized files, duplicated code blocks, and insufficient CI gates. The codebase functions but requires refactoring to reduce coupling and improve error handling. Suitable for immediate use but needs engineering investment for long-term maintainability.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,252 files

JSON109
Python75
Markdown11
HTML11
YAML10
JavaScript8

Django

Module dependencies

The 10 most depended-upon modules of 83, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_desktop_onionshare___init__["__init__"] n1_esktop_onionshare_gui_common["gui_common"] n2_desktop_onionshare_widgets["widgets"] n3_desktop_tests_gui_base_test["gui_base_test"] n4_onionshare_tab_mode___init__["__init__"] n5__onionshare_tab_mode_history["history"] n6_desktop_onionshare_threads["threads"] n7_op_onionshare_connection_tab["connection_tab"] n8_ktop_onionshare_settings_tab["settings_tab"] n9_hare_tab_mode_file_selection["file_selection"] n0_desktop_onionshare___init__ --> n1_esktop_onionshare_gui_common n0_desktop_onionshare___init__ --> n2_desktop_onionshare_widgets n7_op_onionshare_connection_tab --> n0_desktop_onionshare___init__ n7_op_onionshare_connection_tab --> n1_esktop_onionshare_gui_common n7_op_onionshare_connection_tab --> n2_desktop_onionshare_widgets n1_esktop_onionshare_gui_common --> n0_desktop_onionshare___init__ n8_ktop_onionshare_settings_tab --> n0_desktop_onionshare___init__ n8_ktop_onionshare_settings_tab --> n2_desktop_onionshare_widgets n4_onionshare_tab_mode___init__ --> n5__onionshare_tab_mode_history n4_onionshare_tab_mode___init__ --> n0_desktop_onionshare___init__ n4_onionshare_tab_mode___init__ --> n6_desktop_onionshare_threads n4_onionshare_tab_mode___init__ --> n2_desktop_onionshare_widgets n9_hare_tab_mode_file_selection --> n0_desktop_onionshare___init__ n9_hare_tab_mode_file_selection --> n2_desktop_onionshare_widgets n9_hare_tab_mode_file_selection --> n1_esktop_onionshare_gui_common n5__onionshare_tab_mode_history --> n0_desktop_onionshare___init__ n5__onionshare_tab_mode_history --> n2_desktop_onionshare_widgets n5__onionshare_tab_mode_history --> n1_esktop_onionshare_gui_common classDef cyc stroke:#ef4444,stroke-width:2px; class n0_desktop_onionshare___init__,n1_esktop_onionshare_gui_common,n2_desktop_onionshare_widgets,n4_onionshare_tab_mode___init__,n5__onionshare_tab_mode_history,n6_desktop_onionshare_threads,n7_op_onionshare_connection_tab,n8_ktop_onionshare_settings_tab,n9_hare_tab_mode_file_selection cyc;

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

medium4

low1

Declare least-privilege permissions for GITHUB_TOKENmedium3 occurrences

.github/workflows/build.yml

3 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/build.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/build.yml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.