Here’s an example of X11/Xlib being old and archaic.
X11 knows the data type “cardinal”. For example, the window property _NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:
https://en.wikipedia.org/wiki/Cardinal_number
(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)
We would probably call this an “integer” today.
EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:
https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13
So it’s something like 0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.
You would assume that, when you retrieve such an array from the X11 server, you’d get an array of uint32_t, right?
Nope.
Xlib is so old, they use char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:
That is congruent with the general C data types, so it does make sense:
https://en.wikipedia.org/wiki/C_data_types
Now the funny thing is, on modern x86_64, the type long int is actually 64 bits wide.
The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses long int, because uint32_t didn’t exist, yet.
And this is something that I wouldn’t know how to fix without breaking clients.
It annoys me when I clone a git repository A in order to build and self-host some software, only to realize later that I also needed to clone repos B, C and D. I’m not saying that’s a bad thing–logical separation of code between, say, a client and a server is very handy–but some projects do not communicate very well when you need multiple tools to get it running independently.
OpenBSD has the wonderful pledge() and unveil() syscalls:
https://www.youtube.com/watch?v=bXO6nelFt-E
Not only are they super useful (the program itself can drop privileges – like, it can initialize itself, read some files, whatever, and then tell the kernel that it will never do anything like that again; if it does, e.g. by being exploited through a bug, it gets killed by the kernel), but they are also extremely easy to use.
Imagine a server program with a connected socket in file descriptor 0. Before reading any data from the client, the program can do this:
unveil("/var/www/whatever", "r");
unveil(NULL, NULL);
pledge("stdio rpath", NULL);
Done. It’s now limited to reading files from that directory, communicating with the existing socket, stuff like that. But it cannot ever read any other files or exec() into something else.
I can’t wait for the day when we have something like this on Linux. There have been some attempts, but it’s not that easy. And it’s certainly not mainstream, yet.
I need to have a closer look at Linux’s Landlock soon (“soon”), but this is considerably more complicated than pledge()/unveil():
@movq@www.uninformativ.de Me too 😅 – Speaking of which i know you’ve lost a bit of “mojo” or “energy” (so have i of late), rest assured, I want to keep the status quo here with what we’ve built, keep it simple and change very little. What we’ve built has worked very well for 5+ years and we have at least 3 very strong clients (maybe 4 or 5?).
How One Path Traversal in Grafana Unleashed XSS, Open Redirect and SSRF (CVE-2025–4123)
Abusing Client Path Traversal to Chain XSS, SSRF and Open Redirect in Grafana
[Continue rea … ⌘ Read more
How to Play Fortnite on Mac with FnMacAssistant & Sideloadly
Gamers everywhere are happy that Fortnite is back for iPhone and iPad users, but there’s no Mac client in sight (yet anyway). But that doesn’t mean you can’t play Fortnite on the Mac, because if you have an Apple Silicon Mac, and you’re comfortable running some mods and tweaks, you can get the iOS/iPadOS version … [Read More](https://osxdaily.com/2025/05/31/how-to-play-fortnite-on-mac-with-fnmacassistant-sidel … ⌘ Read more
$750 Bounty: for HTTP Request Smuggling on Data.gov
How a cleverly crafted desync attack revealed a hidden path to client-side compromise, JS injection and potential cookie theft
[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/ … ⌘ Read more
#<2025-05-10T19:34:00+00:00 https://andros.dev/texudus.txt> Nice:) And is this implemented in your client as well? I’ve started to brainstorm on how to parse texudus in php, but I guess it could snatch some code from you?
GitHub for Beginners: Building a React App with GitHub Copilot
Follow along and build a frontend client using React and Copilot Chat.
The post GitHub for Beginners: Building a React App with GitHub Copilot appeared first on The GitHub Blog. ⌘ Read more
MCP 超強源碼解讀!Streamable HTTP 如何實現服務端向客戶端通信
在最新的 Model Context Protocol(MCP,模型上下文協議)版本(2025-03-26)[1] 中引入了 Streamable HTTP 的通信方式,取代了舊版本中的 SSE 通信方式,成爲了新的遠程 MCP 調用標準。Streamable HTTP 通信下的 client 向 server 的請求不需要像之前必須保持 SSE 的長連接,而是通過 client 發起 HTTP ⌘ Read more
UUIDs: A False Sense Of Security
Hi Hunters, would you like to learn about a broken access control vulnerability that I discovered recently for a client.
[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/uuids-a-false-sense-of-security-10467497daae?source=rss—-7b7 … ⌘ Read more
@<nick url timestamp>) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.
@sorenpeter@darch.dk Unfortunately it does break all clients, because the original spec stated:
Mentions are embedded within the text in either @ or @ format
Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.
@bender@twtxt.net My point was that the suggested syntax for extending mentions to point to a specific message (@<nick url timestamp>) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.
Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.
@sorenpeter@darch.dk you wrote:
“This might even be backward compatible with older (pre-yarn) clients.”
Yarnd is as backwards compatible with older clients as this. I dare to say, even more so. 😅
@andros@twtxt.andros.dev Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients.
What about using Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I’m still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.
@andros@twtxt.andros.dev @eapl.me@eapl.me Still lots of bugs in my client. 🥴 I’ll try to fix it next week.
And yes, using the same timestamp twice will very likely break threads.
@andros@twtxt.andros.dev I set up a test feed here:
https://www.uninformativ.de/texudus.txt
I made some preliminary adjustments to my client so that it can work with the different threading model. (And I totally get the concerns, this can be quite a bit of work. Especially in a large code base like Yarn.)
if clauses to this. My point is: Every time I see a hash, I’d like to have a hint as to where to find the corresponding twt.
@movq@www.uninformativ.de I think we can make this work 👌 As long as it’s just a client hint.
@movq@www.uninformativ.de If we’re focusing on solving the “missing roots” problems. I would start to think about “client recommendations”. The first recommendation would be:
- Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).
This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.
從 0 開始實現 MCP-Client
什麼是 MCP-Client?MCP-Client是Model Context Protocol(模型上下文協議)架構中的一個重要組件,用於連接AI模型(如Claude、GPT等大型語言模型)與外部數據源、工具和服務的橋樑。MCP(Model Context Protocol)是由Anthropic公司在 2024 年底首次提出並開源的一種開放標準協議,旨在解決大語言模型(LLM)與外部世界的連接 ⌘ Read more
@lyse@lyse.isobeef.org likewise I don’t have the energy for a fundamental shift in any of our specifications that would inevitably cause a lot of toil and try and change in our clients implementations and unforeseen problems that we haven’t really fully understood:
twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience
@lyse@lyse.isobeef.org Hahahaha 🤣 I mean it’s “okay” every now and then, but what’s the point of having good clients and tools if we don’t use ‘em 🤣
7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update
We have 4 clients but this should be 6 I believe with tt2 from @lyse@lyse.isobeef.org and Twtxtory from @javivf@adn.org.es?
Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! – I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social’s 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update
And speaking of Twtxt (See: #xushlda, feeds should be treated as append-only. Your client(s) should be appending Twts to the bottom of the file. Edits should never modify the timestamp of the Twt being edited, nor should a Twt that was edited by deleted, unless you actually intended to delete it (but that’s more complicated as it’s very hard to control or tell clients what to do in a truely decentralised ecosystem for the deletion case). #Twtxt #Client #Recommendations
Just like we don’t write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience
Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation
@javivf@adn.org.es Ahh! So this is your client implementation? 🧐
Was just looking at the client you’re using Twtxtory 🤔 Very nice! 👍 is this your client, did you write it? I’d not come across it before!
$ bat https://twtxt.net/twt/edgwjcq | jq '.subject'
"(#yarnd)"
hahahahaha 🤣 Does your client allow you to do this or what? 🤔
Interesting factoid… By inspecting my “followers” list every now and again, I can tell who uses a client like jenny, tt or any other client where fetches are driven by user interactions of invoking the app. What do we call this type of client? Hmmm 🤔 Then I can tell who uses yarnd because they are “seen” more frequently 🤣
Steam to highlight accessibility support for games on store pages
The Steam store and desktop client will soon be able to help players find games that feature accessibility support. If your game has accessibility features, you can now enter that information in the Steamworks ‘edit store’ section for your app. ↫ Steam announcements page I have a lot of criticism for the Steam client application – it’s a overly complex, unattractive, buggy, slow, top-heavy Chrome engi … ⌘ Read more
OSTIF Announces NATS Security Audit Results
OSTIF is proud to share the results of our security audit of NATS. NATS is an open source project made by Synadia Communications for secure always-on messaging for a variety of digital formats and clients. With… ⌘ Read more
My Hypothesis for why registries didn’t work and why they still won’t really work today is because the bend the rules of “true” decentralization a bit. Users have to pick one or more registries to “register” to. Why would they want to do this? What is their incentive to do so? Then on the other hand, users need a client that has registry support, but now which registry or sets of registries do you choose?
@bender@twtxt.net You said:
as long as those working on clients can reach an agreement on how to move forward. That has proven, though, to be a pickle in the past.
I think this is because we probably need to start thinking about three different aspects to the ecosystem and document them out:
- Specifications (as they are now)
- Server recommendations (e.g: Timeline, yarnd, etc)
- Client recommendations (e.g: jenny, tt, tt2, twet, etc)
@andros@twtxt.andros.dev nothing stands still, I agree. I think current twtxt has surpassed the initial specification, while still being relatively backwards compliant/compatible but, for how long?
As for new extensions (DM, for example), they should be OK as long as those working on clients can reach an agreement on how to move forward. That has proven, though, to be a pickle in the past.
yarnd UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:
The nice thing here is that any Ui/UX rendering for a “good user experience” is similar to what yarnd does for Youtube/Spotify/whatever embedding. Plus anyone can participate, even if they don’t really have a client that understand it, it’s just text with some “syntax” afterall.
(#6kkpdda) The nice thing here is that any Ui/UX rendering for a “good user experience” is similar to what yarnd does for Youtube/Spotify/what …
The nice thing here is that any Ui/UX rendering for a “good user experience” is similar to what yarnd does for Youtube/Spotify/whatever embedding. Plus anyone can participate, even if they don’t really have a client that understand it, it’s just text with some “syntax” afterall. ⌘ Read more
💡 I had this crazy idea (or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could be really useful additions to the yarnd UI/UX experience (for those that use it) and as “client” features (not spec changes). The two ideas are quite simple:
- Voting – a way to cast, collect a vote on a decision, topic or opinion.
- RSVP – a way to “rsvp” to a virtual (pr physical) event.
Both would use “plain text” on top of the way we already use Twtxt today and clients would render an appropriate UI/UX.
💡 I had this crazy idea (or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could …
💡 I had this crazy idea ( or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could be really useful additions to the yarnd UI/UX experience ( for those that use it) and as “client” features ( not spec changes). The two ideas are quite simple:
Voting – a way to cast, collect a vote on a decision, topic or opinion.
RSVP – a way to “ … ⌘ Read more
@kat@yarn.girlonthemoon.xyz At the core, you need an ngircd.conf like this:
[Global]
Name = your.irc.server.com
Password = yourfancypassword
Listen = 0.0.0.0
Ports = 6667
AdminInfo1 = Well, me.
AdminInfo2 = Over here!
AdminEMail = forget.it@example.invalid
[Options]
Ident = no
PAM = no
[SSL]
CertFile = /etc/ssl/acme/your.irc.server.com.fullchain.pem
KeyFile = /etc/ssl/acme/private/your.irc.server.com.key
DHFile = /etc/ngircd/dhparam.pem
Ports = 6669
Start it and then you can connect on port 6667. (The SSL cert/key must be managed by an external tool, probably something like certbot or acme-client.)
I’m assuming OpenBSD here. Haven’t tried it on Linux lately, let alone Docker. 😅
restic for that reason and the fact that it's pretty rock solid. I have zero complaints 😅
@prologic@twtxt.net I also thought it was a client-server thingy at first and usually it is, I guess, there’s just this workaround:
If it is not possible to install Borg on the remote host, it is still possible to use the remote host to store a repository by mounting the remote filesystem, for example, using sshfs.
is it like… ethical to offer access to certain self hosted services as patreon exclusives. like i wanna offer the IRC client/bouncer i hosted which seems ok i think because i’ve seen pico.sh offer their instances of that as paid services. but the other ones i have in mind are alt web frontends for stuff like imgur and pinterest. and i just feel weird about it for some reason. idk i’m trying to think of ways to support my server stuff but every time i come up with something it feels weird
@prologic@twtxt.net oooh this looks interesting!!! maybe i could play around with it in docker and see how to integrate it with caddy layer4 for TLS + my existing web client and bouncer!!