Luciano AguileraAug 26, 2025
Aca programando y dandole matraca a la libreria grafica de bajo nivel XCB, dentro de un docker con Alpine Linux.
Es mas rapido, chiquito (no dependencias) y directo que la famosa SDL, pero al precio de escribir mas, es mas complejo por que expone el subsistema X sin pudor! , y lo peor , muy poca documentacion ! Y ni la IA te salva ! Cual es mi meta (ya perdida) ? escribir el backend de la libreria Nuklear solo en xcb, luego usar la como interfaz para otro proyecto mas loco tipo juego Cataclysm DDA o Space Station 13 (MMORPG)... Pero casi seguro va derecho al cementerio. Pero es la diversion (o locura?) de hacer que aparezca algo en pantalla y se mueva... terrible.... #xcb #graphics #x11 #xlib #linux #gui
CosicBeJun 12, 2025
Excited to announce that our paper with TU Wien on the first plaintext recovery attack against XCB-AES (IEEE 1619.2) has been accepted at #CRYPTO2025!
šŸ‘‰ https://ia.cr/2024/1554
#IEEE #Standardization #XCB #XCB_AES #cosic #kuleuven
Breaking the IEEE Encryption Standard ā€“ XCB-AES in Two Queries

Tweakable enciphering modes (TEMs) provide security in various storage and space-critical applications, including disk and file-based encryption and packet-based communication protocols. XCB-AES (originally introduced as XCBv2) is specified in the IEEE 1619.2 standard for encryption of sector-oriented storage media and comes with a formal security proof for block-aligned messages. In this work, we present the first plaintext recovery attack on XCB-AES $-$ the shared difference attack, demonstrating that the security of XCB-AES is fundamentally flawed. Our plaintext recovery attack is highly efficient and requires only two queries (one enciphering and one deciphering), breaking the claimed $\mathsf{vil\text{-}stprp}$, $\mathsf{stprp}$ as well as the basic $\mathsf{sprp}$ security. Our shared difference attack exploits an inherent property of polynomial hash functions called separability. We pinpoint the exact flaw in the security proof of XCB-AES, which arises from the separability of polynomial hash functions. We show that this vulnerability in the XCB design strategy has gone unnoticed for over 20 years and has been inadvertently replicated in many XCB-style TEM designs, including the IEEE 1619.2 standard XCB-AES. We also apply the shared difference attack to other TEMs based on XCB $-$ XCBv1, HCI, and MXCB, invalidating all of their security claims, and discuss some immediate countermeasures. Our findings are the first to highlight the need to reassess the present IEEE 1619.2 standard as well as the security and potential deployments of XCB-style TEMs.

IACR Cryptology ePrint Archive
a66ey šŸ‡ŖšŸ‡ŗšŸ³ļøā€šŸŒˆ she/herDec 3, 2024

So I just wrote myself a kb language layout indicator for #x11 to complement my #twm setup and #tmux status panel while at it. This #c thing seems quite useful. Yay me 

#freebsd #linux #unix #hobbyhack #noob #xcb

Show threadzirias (on snac)Oct 12, 2024
A major blocker could be that it relies on my "poser" project: https://github.com/Zirias/poser ... it's a small lib, so you could certainly integrate the parts needed, but I didn't do it, I just made #Xmoji build with a bundled (statically linked) #poser by default instead. Another blocker could be that it does quite some trickery to force #xcb into an #async model with #events and registered event-handlers (provided by poser), so it integrates well with a generic event loop built on #select (which poser does, anything else based on file descriptors like #poll, #epoll, #kqueue would work as well). It abuses xcb functions meant for tracing/debugging for that purpose. šŸ™ˆ

And then, of course, it's very different from #Xt. It strictly requires #XRender, using its "picture" objects as the primary drawing handle, and just offering the core X11 "drawable" on demand. It strictly requires a "true color" visual. It has NO support whatsoever for core drawing primitives and core (bitmap) fonts. It doesn't create a window for every widget but instead manages widgets fully client-side ... all these are probably not "blockers" but just how you'd design a GUI toolkit for X11 nowadays šŸ˜‰
GitHub - Zirias/poser: POsix SERvices framework for C

POsix SERvices framework for C. Contribute to Zirias/poser development by creating an account on GitHub.

GitHub
Show threadzirias (on snac)Oct 12, 2024
Haha, well, I'd stick to putting "#toolkit" in quotes only. For once, it's entirely non-portable to anything other than #X11 (with #XRender) via #xcb (like e.g. #wayland or #GDI) ... xcb types/interfaces are hardwired practically everywhere. And then, although it might be possible to extend it to some "generic" toolkit specifically for that platform, I have no plans doing so. I strictly only implemented what was necessary for #Xmoji's GUI. šŸ˜‰
zirias (on snac)Oct 2, 2024
You might have noticed development of #Xmoji slowed down a bit. My time is currently very limited, but another reason is slowly closing in on a version 1.0, and I want to give it some time for proper testing.

I need your help, please! šŸ˜

Xmoji 0.8 introduced an important part for #i18n, translations. But I'm not exactly fluent in many languages. Please, if you can, help me translate! The process is documented in https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md . If there are any issues with these instructions, please let me know.

Xmoji aims to be the "best" tool to input emojis with "pure" X11:

  • Written in plain #C, with minimal dependencies
  • Uses #Xrender for its UI, communicates with the X server using #xcb
  • Offers two methods for input: Faked keyboard events or the "primary selection"
  • Has a search tab and a list of recently used emojis
  • Customizable appearance using X resources
  • Several options to configure key injection and the search method

Roadmap to V1.0:

  • Optional single-instance mode
  • Optional tray icon

#X11 #emoji #keyboard
xmoji/TRANSLATE.md at master Ā· Zirias/xmoji

Plain X11 emoji keyboard. Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub
Show threadFelix Palmen  Sep 30, 2024
@krausedw I wonder whether I should try to create a "toolkit" (that would ONLY work with #X11 and #Xrender) out of the small collection of "widgets" I created in #C / #xcb for #Xmoji, just to publish more stuff intentionally incompatible with #Wayland... šŸ˜
Felix Palmen  Aug 2, 2024

#xcb #development thoughts:

One of the features I'd like to add to #Xmoji is a "system #tray icon". I know these aren't "en vogue" any more, but I like the concept a lot for an application you'll typically leave running and only use from time to time, which is likely a usage pattern for an "#emoji #keyboard".

So, I found a spec based on #XEMBED, X selections and client messages (therefore, pure X inter-client communication), I think I can implement that! šŸ‘
https://specifications.freedesktop.org/systemtray-spec/0.2/

Digging deeper, I found there's a successor called #SNI and the spec above is considered "legacy" (after only 20 years, hehe) šŸ¤Ø. SNI is based on #dbus. Oh damn ... it's not that I particularly hate dbus, it probably makes a lot of sense for complex desktop environments, but I really want to keep #Xmoji "plain #X11". I'll just use the old spec. At least I found #KDE seems to have a compatibility service: xembed-sni-proxy. No idea about Gnome. But then, screw it.

System Tray Protocol Specification

1 Overview # The system tray is an application running on a given X screen that can display small icons provided by running applications. Windows XP calls this feature the notification area. [1] Inspired by KDE, this specification uses the term system tray. From a UI standpoint, the system tray is nā€¦

Felix Palmen  Aug 1, 2024

Finally removed the nasty "glitches" setting from #Xmoji!

After lots of (unsuccessful) research whether I can somehow check which modules(!) are loaded on the X server (to find out whether #GLAMOR is used, which I *think* causes a bug in compositing glyphs with #XRender) ... I finally remembered an old strategy which is both horribly ugly and pretty reliable: probing!

I now do a dummy glyph compositing to a single-pixel off-screen pixmap during startup and fetch the resulting pixmap from the server, so I can simply *see* whether the result is buggy. šŸ™ˆ

https://github.com/Zirias/xmoji/commit/93143775e6ad9b01f7f23b2da48c5e6921669fd0

I actually wonder why I didn't have that idea much earlier. E.g. coding on the #C64, probing the hardware (e.g. to identify VIC and SID model by their behavior) is a pretty common thing to do šŸ„ø

#X11 #emoji #keyboard #xcb #programming

X11Adapter: Add code probing for rendering glitch Ā· Zirias/xmoji@9314377

Add code compositing a dummy glyph to a 1px offscreen pixmap with an y offset of 1 pixel. This should result in nothing. If the one pixel is set nevertheless, we know we're on a system with bug...

GitHub
Show threadFelix Palmen  Jul 31, 2024

In case anyone is interested, this is how this exercise looks like:

https://github.com/Zirias/xmoji/blob/9265f2d8f8633868720259f25cbad8eaa0df2c11/src/bin/xmoji/textbox.c#L106

The point coordinates for the consecutively rendered triangles are in the arrays "points" (the "background") and "x1points" and "x2points" (the "X") šŸ¤Ŗ

#X11 #xcb #programming

xmoji/src/bin/xmoji/textbox.c at 9265f2d8f8633868720259f25cbad8eaa0df2c11 Ā· Zirias/xmoji

Plain X11 emoji keyboard. Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub