HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
CyberShadow
hax11
C2018–2022
CyberShadow / hax11

hax11

Hackbrary to Hook and Augment X11 protocol calls

Explore on GitHubRead Hacker News discussions
2Distinct people
5Mentions
0Explicit recommenders
129GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Hackbrary to Hook and Augment X11 protocol calls

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year5 dated mentions

Observed mentions: 2018-06-01 12:33:29 UTC to 2022-02-05 11:23:46 UTC.

0122018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202

What Hacker News says

5 sources
CyberShadow·Feb 5, 2022
Currently writing a clipboard manager[1], I've seen some things as well. - So far ran into two applications which don't even implement the X11 clipboard specification (ICCCM section 2) correctly - xsel and Emacs (patches submitted). - By far the worst offense I've seen in clipboard privacy on the Linux desktop is RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines, even when they are not focused, with no indication that it's happening, and with no GUI option to turn it off. This is at odds with the common practice of running untrusted code in virtual machines. - X11 being network-transparent makes its protocol fairly malleable, so it's not difficult to bolt some privacy on top. hax11[2] has an option to restrict access to the primary selection for configured applications (though, for truly maliciou
Read the rest
s applications, you may find X11's security model generally lacking). [1]: https://news.ycombinator.com/item?id=29808487 [2]: https://github.com/CyberShadow/hax11
In Who keeps an eye on clipboard access?
CyberShadow·Jan 5, 2022
From a security perspective, I don't think it's possible to do with the standard OS APIs. When an application makes data available in the clipboard, it's a free-for-all for every other application. The clipboard manager would have to race other applications to make a copy of the data, and then empty the OS clipboard. APIs also may not allow making decisions based on which application requested the clipboard. It's possible to do in X11, but not Windows. This goal could be achievable by intercepting the OS clipboard API. On X11, this can be done by MITM-ing the connection to the X server - https://github.com/CyberShadow/hax11 does this, and already has one clipboard-related security feature (disabling the selection mechanism). On Windows, the best bet is probably global DLL injection and API hooks, but applications can "opt out" by running
Read the rest
as a different user or requesting a higher integrity level.
In The weight of the clipboard
CyberShadow·Jul 20, 2020
Speaking as Worms Armageddon maintainer: Yes, of course we want to port the game to run natively on more platforms. There's just some really non-trivial technical obstacles in the way. For instance, the game relies on an internal framework called DXMFC for its UI, which is entirely based on MFC, Microsoft's UI toolkit. Speaking as a full-time Linux users since 2016: I found that getting old (i.e. unmaintained) native Linux games to work again is MUCH harder than running their Windows version. E.g., I spent hours trying to get the Linux port of Unreal Gold to work with no luck, and in the end had to give up and run the Windows version under Wine. There is just so much change on the Linux desktop that old software is just not going to behave well. Not only do you usually need to reproduce the entire userspace from the time the game is relea
Read the rest
sed (and of the distro that it was built against), but changes in display APIs (Xinerama, XRandR, SDL versions...) often result in full-screen or resolution problems. This is a project I wrote to work around exactly issues like this: https://github.com/CyberShadow/hax11
In Worms Armageddon 3.8
CyberShadow·Feb 10, 2019
Thank you. From what I've seen, Wayland seems to follow a very narrow set of use cases, and willfully ignores others outside its philosophy, no matter what their practical applications might be. From what I remember reading previously: - Wine is unimplementable in Wayland. By design. - Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys. (Desktop enviroments may provide APIs for this, but then you get the foreseeable issues with using e.g. KDE apps on Gnome. And what if you don't want a desktop "environment"?) - Screenshotting and screen casting tools are unimplementable in Wayland, by design. - Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and requir
Read the rest
e individual support for each Wayland implementation in each program, thus causing further fragmentation. - I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great. I can certainly think of situations where Wayland's advantages greatly outweigh its drawbacks, but its philosophy seems so much at odds with at least the way I interact with my computer, that the idea of switching to Wayland seems completely unfathomable. As far as I can see, at this rate, Xorg will live forever. I've been instead working on my own little tool to fix the few annoyances in Xorg clients that I ran into (the ease with which I've achieved this and the flexibility of the tool speaks further in Xorg's favor): https://github.com/CyberShadow/hax11
In Exposing the Wayland lie (2018)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.