This took me quite a bit of time, but I managed to boot postmarketOS on a currently unsupported devboard (commonly available for €25-30 where I live).
Little bit proud, but it's not a proper port yet, I ripped the kernel and other parts of the pre-init bootchain (fip.bin, u-boot, ...) from a pre-made Debian image for that device. I have a (mostly working) APKBUILD for that device's userland though. :)
I pushed curl-rustls-8.19.0-3-x86_64.pkg.tar.zst to Arch Linux, with this version it's now possible to encrypt the TLS client hello:
curl-rustls -sSv --ech hard --doh-url='https://dns.mullvad.net/dns-query' 'https://defo.ie/ech-check.php'
Should display:
<p>SSL_ECH_OUTER_SNI: cover.defo.ie <br />
SSL_ECH_INNER_SNI: defo.ie <br />
The --doh-url is mandatory, otherwise curl won't query the `https` dns records (dig +short https defo.ie).
For opportunistic ECH use `--ech true`.
Now the problem, if I run `git init` without `--object-format=sha256` I won't be able to fetch a sha256 repository I add with `git remote add` afterwards. Is there a "proper" way to fix this? Best I could come up with is `git ls-remote 'https://codeberg.org/kpcyrd/ssh-keyonly.git' | cut -f1` and count the oid length? #git
Asking for support from my fellow followers: I recently mentioned I'm field-testing sha256 git repositories, I now noticed something that broke and I'm wondering what's the best way to fix this.
I have code that fetches one specific revision from a git repository (by tag name or commit id). The way I'm doing this is somewhat involved, since it's not properly supported in git, and it involves running `git init -qb main` on my end.
I did a writeup of things I was working on in 2025: https://vulns.xyz/2025/12/2025-wrapped/
There's also an curl-rustls Arch Linux package that dynamically links to rustls instead of openssl, however #curl still considers this experimental:
In other news, very happy to see the most popular #Rust http client library is switching their default TLS implementation from OpenSSL to #rustls.
https://github.com/seanmonstar/reqwest/releases/tag/v0.13.0-rc.1
I've published a writeup about the ongoing `hashFiles` incident on #Github Actions - the source code seems to mismatch whats actually in the Runner VM image:
https://lists.reproducible-builds.org/pipermail/rb-general/2025-November/003941.html
The sudo-rs CVE-2025-64517 is all over the news, but it looks like it's not really exploitable in the wild?
It's a very cool find and I'm glad it's fixed, but it's not the unconditional local-root that people seem to think it is? Going from www-data to root with this bug seems to be almost impossible in the real world/outside of CTFs? #rust #sudo
In 2025 your options when making a website as a non-webdev person are "everybody is upset because it looks AI generated", "everybody is upset because it's bootstrap" and "everybody is upset because you decided the only css is going to be `body { background-color: #db7093; font-family: sans-serif; }`".
If you do #embedded #Rust on the #rp2040 with elf2uf2-rs, and you struggle with the recent "Unrecognized ABI" error due to a change in Rust's elf header for `thumbv6m-none-eabi`, I've landed StripedMonkey's patch in both Arch Linux and Homebrew, so if you use those packages, things should work out of the box again.