it's funny how people ping me on issues and pull requests as if I haven't read 100% of the notifications of ziglang/zig for the last 10 years
you might as well be pinging the eye of sauron
#curl security report number **eight** within the last seven days was just received. And as 8 out of 8 it will be closed as not applicable.
This is roughly 4x our normal average frequency. No clue as to why this peaks now.
We clearly need to raise the bar somehow to stop sand from getting into the machine.
TIL: Ever wanted to compress data or use cryptographic algorithms but you don't want to link to C libraries or you're just plain lazy?
The Linux kernel has you covered! Create a socket of type AF_ALG, bind to your favorite algorithm, send() in your data and recv() it back!
This seems to support deflate, SHA, RSA and some more on ppc64le and additionally even zstd, chacha, lzo, hmac and more on ARM!
https://www.kernel.org/doc/html/latest/crypto/userspace-if.html
This is all very efficient to secure services, but it's also a bit opaque: since it's the daemon you sandbox, and your admin tools are outside of that sandbox it's sometimes hard to analyze how the daemon sees things.
No more. With v258 there's a new verb "unit-shell" in systemd-analyze. You specify a service name, and it opens you a shell inside that specified services' sandbox (which must be running for this). You can look around and check if everything is like you expected it to be.
Today, I heard someone say they work from 09:00 to 23:00 every day as if that was something good
I mean, I already do a lot more than is probably healthy, but it’s way less than that!
No human should have to do that, let alone be proud of it 😲 This sets a terrible example / expectation
@ariadne As the person responsible for most of the initial work to make Linux utilities use PAM, including some that are SUID, thus introducing the first use of dlopen() into at least some of them, and as someone who has written a fair share of patches to fix security exploits, and been responsible for reviewing and delivering lots of other security updates...
I do not trust myself to write a secure SUID program, generally.
I'd rather move away from SUID for privilege escalation entirely to more robust and nuanced alternatives.
If you don't have SUID programs, you won't have any SUID programs calling dlopen()... 😎
But yeah, inasmuch as we still use SUID programs, I'd much rather they not dlopen() anything.
PSA: So you want to be a good kid, and understand that UNIX file system paths are kind wonky, and not stable references to inodes. So you drink the Linux cool-aid, and become a heavy O_PATH user: you pin all inodes via fds, validate them before you open them, use openat() heavily to get from one inode to descendents and are extra careful everywhere. And you think you saw the light.
But then one day, you realize, you *actually* have been doing it all wrong.
Ghostty's sprite renderer got a major refactor by our font maintainer (Qwerasd). We now support more sprites and they line up perfectly on cell edges. Additionally, our sprites now pack more efficiently on the GPU to save some VRAM. Comparison between terminals as an example.
Ghostty's always had a built-in sprite renderer (actually, rasterizer). The job of the rasterizer is to generate pixel-perfect sprites dynamically for a given grid size.
Practically, this results in much more aesthetically pleasing shell prompts, powerline bars, etc. And things like circles that line up perfectly make for better TUIs.
Some additional amazing background: the rasterizer uses a 2D graphics library written in Zig specifically for Ghostty by a community member (but generalized: https://github.com/vancluever/z2d). And while I wrote the initial rasterizer, the major work since has been by our font subsystem maintainer Qwerasd who has taken it to new, incredible levels. ❤️
Andrew Kelley
daniel:// stenberg://
Adrian
Lennart Poettering
Michael Stapelberg 🐧🐹😺
Michael K Johnson
Armin Rohde
Matthew Garrett
Mitchell Hashimoto