{"id":26253053,"url":"https://github.com/petercxy/wl-mitm","last_synced_at":"2026-04-27T09:31:02.090Z","repository":{"id":279535963,"uuid":"939096854","full_name":"PeterCxy/wl-mitm","owner":"PeterCxy","description":"Mirror of https://gitea.angry.im/PeterCxy/wl-mitm","archived":false,"fork":false,"pushed_at":"2025-12-12T03:32:39.000Z","size":505,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-12-29T02:34:31.548Z","etag":null,"topics":["security","wayland"],"latest_commit_sha":null,"homepage":"https://gitea.angry.im/PeterCxy/wl-mitm","language":"Rust","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/PeterCxy.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-02-26T01:36:28.000Z","updated_at":"2025-12-12T03:32:43.000Z","dependencies_parsed_at":"2025-12-27T12:03:25.607Z","dependency_job_id":null,"html_url":"https://github.com/PeterCxy/wl-mitm","commit_stats":null,"previous_names":["petercxy/wl-mitm"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/PeterCxy/wl-mitm","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PeterCxy%2Fwl-mitm","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PeterCxy%2Fwl-mitm/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PeterCxy%2Fwl-mitm/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PeterCxy%2Fwl-mitm/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/PeterCxy","download_url":"https://codeload.github.com/PeterCxy/wl-mitm/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PeterCxy%2Fwl-mitm/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32331305,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-26T23:26:28.701Z","status":"online","status_checked_at":"2026-04-27T02:00:06.769Z","response_time":128,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["security","wayland"],"created_at":"2025-03-13T17:29:41.869Z","updated_at":"2026-04-27T09:31:02.054Z","avatar_url":"https://github.com/PeterCxy.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"wl-mitm\n---\n\n`wl-mitm` is a filtering man-in-the-middle proxy for Wayland compositors.\nThrough a toml config file, it allows you to selectively enable only a necessary subset of Wayland protocols\nfor apps to function.\n\nWayland's core protocols are generally safe to expose to any program, but there are extensions that could\npotentially be abused. For example, [wlr-screencopy-unstable-v1](https://wayland.app/protocols/wlr-screencopy-unstable-v1).\nA sandboxed program may be able to make use of these extensions to \"escape\", at least in the sense of accessing\nscreen content, clipboard, etc.\n\nMoreover, access control to sensitive protocols implemented in different compositors may be wildly different.\nAlthough something like [security-context-v1](https://wayland.app/protocols/security-context-v1) exists, what ends up\nbeing exposed is still determined by the compositor and this behavior is usually not programmable by the end user.\n\n`wl-mitm` solves this by _proxying_ the Wayland socket and exposing a very flexible configuration format to\nyou, the user. You can elect to allow any subset of Wayland protocols you would like an application to have access\nto, or even filter specific _requests_ provided that clients can handle a missed message well. `ask_cmd` and\n`notify_cmd` combines this filtering capability with arbitrary extensibility through external programs. For example,\nan `ask_cmd` may show a prompt to the user whether to allow a certain Wayland request to proceed. A `notify_cmd`\nmay send a desktop notification when an application performs a senstive action through a Wayland request.\nThis also makes it potentially a very useful debugging tool.\n\n`wl-mitm` is intended to be used _on top of_ some other sandboxing system that, at the very least, limits\na program's access to the rest of the filesystem. Otherwise, a malicious application can simply access the original,\nunadulterated Wayland socket directly under `$XDG_RUNTIME_DIR`.\n\nBuilding\n---\n\n`wl-mitm` requires a Rust compiler supporting Rust 2024.\n\n`wl-mitm` relies on generated code and does not use `build.rs` or `proc_macro`s due to performance issues with\n`rust-analyzer`. Instead, run `./generate.sh` to generate Rust parser code based on Wayland protocol XMLs located\nunder `proto/`.\n\nAfter running `./generate.sh`, simply run `cargo build --release` to produce a release binary.\n\nUsage\n---\n\nRun `wl-mitm` with\n\n```\nwl-mitm \u003cpath/to/configuration/file\u003e\n```\n\nPath to the configuration file defaults to `./config.toml`.\n\nThis repo contains an example configuration at `config.toml` that allows a few base Wayland protocols for standard\ndesktop apps to function. It also demonstrates the use of `ask_cmd` and `notify_cmd` by defining filters on clipboard-related\nrequests. Detailed explanation of the configuration format is also contained in the example.\n\nTo launch a program under `wl-mitm`, set its `WAYLAND_DISPLAY` env variable to whatever `listen` is under `[socket]` in `config.toml`.\nNote that you may want to use another container and pass _only_ the `wl-mitm`'d socket through for proper isolation.\n\nA Word on Filtering\n---\n\n`wl-mitm` gives you a ton of flexibility on filtering. In particular, you are allowed to filter _any_ request on _any_ object\nin `config.toml`.\n\nHowever, please keep in mind that while most requests can be filtered, Wayland (and most of its protocols) is not designed to handle\nthis type of filtering. While a lot of requests can be filtered without consequences, there are a significant number of them that\nwill result in irrecoverable de-sync between the client and the server. For example, _any_ message that creates a new object ID\n(of the type `new_id`) _will_ result in undefined behavior if filtered.\n\n`wl-mitm` does provide the ability to _reject_ a request with an explicit error. Unfortunately, errors in Wayland are usually\nfatal, and clients are not designed to recover from them.\n\nThe most reliable (and the only protocol-compliant) way to prevent a client from using certain features is to block the\nentire global object where that feature resides. These are usually \"manager\" objects that live in the global registry,\nand can be blocked in `allowed_globals` inside `config.toml`. Each extension protocol has to expose _some_ manager object\nin order for clients to access their functionalities, and thus blocking them there will prevent clients from even knowing\ntheir existence. However, globals can't be selectively blocked using `ask_cmd`, because clients usually bind to them as soon\nas they start.\n\nSince `notify_cmd` never blocks a request, it is safe to use on _any_ request filter.\n\nXWayland\n---\n\n`wl-mitm` is explicitly _not_ a sub-compositor. This also means that it can't support XWayland natively like some\nsubcompositors do, such as [sommelier](https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/main/vm_tools/sommelier/) from\nChromeOS. The decision to _not_ implement it as a sub-compositor is made to ensure maximum compatibility with Wayland\nprotocols and compositors, and to introduce as little additional quirks as possible over the host compositor.\n\nIf you would like to use XWayland over a socket filtered by `wl-mitm`, here are a few options:\n\n1. Use Sommelier's X mode only;\n2. [xwayland-satellite](https://github.com/Supreeeme/xwayland-satellite) is a compositor-agnostic XWayland implementation in Rust;\n3. [gamescope](https://github.com/ValveSoftware/gamescope) is an XWayland-only subcompositor specifically intended for games.\n\nSupported Protocols\n---\n\n`wl-mitm` aims to include support for all known, non-deprecated Wayland protocols. This is currently achieved by\npulling in all XMLs from the [wayland-explorer](https://wayland.app) project.\n\nThe `update-proto.sh` script is responsible for updating the list of XMLs used to generate Wayland parsers.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpetercxy%2Fwl-mitm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpetercxy%2Fwl-mitm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpetercxy%2Fwl-mitm/lists"}