Artificial truth

The AI-authored Denial-of-Service attack

jvoisin — Tue, 07 Jul 2026 15:45:00 +0200

In 2020, my friend anarcat published the CLA Denial-Of-Service attack, an interesting musing on the possibility of weaponising CLA, boiling down to:

find a critical bug
figure out a [non-trivial] patch for the bug
publish the patch in their issue tracker
forever refuse to sign the CLA

The obvious solution to this conundrum is to perform clean-room reimplementation: have a person read the patch and produce a specification, then have a second distinct person read the specification and produce a patch. It's not a silver bullet, as the less trivial the change, the lengthier the specification, and thus the lengthier and complexer the implementation. And because of course, complexity doesn't scale linearly, large changes are horribly annoying to reimplement.

On the bright side, there is a symmetry in the efforts: an attacker has to spend time to create a non-trivial change that warrants the effort of being clean-room'ed. The ubiquitousness of LLM didn't change this balance, it only lowered the costs for both sides: telling the AI God du jour to write code is cheap, and so are clean room reimplementations. While pure-AI outputs can't be copyrighted, having an actual person shepherding it and sprinkling some authentic human changes and touches it cheap and should be enough to stamp a copyright on top of it.

But not everyone is comfortable with code produced by AI/LLM, with some projects banning code that isn't 100% human-created. This introduces an imbalance, as having someone volunteer to read the changes and produce a spec that could then be used by a different person to implement the fix is orders of magnitude more costly for the project than for an attacker to generate slop, likely wing to Brandolini's law

Slop can, of course, be ignored, and small desirable improvements are trivial to reimplement, so besides identifying slop, it's not a big issue anyway. An easy way to spice things up would be to find a security issue with a non-trivial but-still-straightforward fix, send a pull-request with Co-authored-by: Claudepilchat, and argue that the clean-room reimplementation is erringly similar to LLM one, which would be a license violation, gasp!

Another more impactful possibility would be to use a time bomb, by sending a proper legit-looking invasive change. It could be reviewed, merged and shipped, only for the author to reveal, 3 months later, that the change was actually done by an LLM, oops-sorry-I-forgot. Would the project spend time in doing a tedious reversing of all the changes? If so, what if the change was addressing a complex security issues? If the change isn't reversed, does it mean that the "no LLM" policy is selectively applied?

Now, I'm not a fan of the "incinerating the planet and feeding unfathomably high amounts of human-needed resources to train glorified text-prediction engines so that we can all drown in slop and witness every artistic endeavour be sucked dry and regurgitated in the form of soulless copy-pasta every-fucking-where" plan, and I think it would be real nice to stop implementing it right now. But, on the other hand, I don't think that a self-righteousness attitude is the appropriate position to adopt: people are going to send slop to your project, people are going to cheat, it will happen. Having a pragmatic position on this mess, like "we ask you not to use LLM in any way, shape or form, don't be a dick" paired with a trusty trigger-happy ban-hammer conveys the same message while avoiding painting your project into a corner.

Markdown outline in (neo)vim with fzf

jvoisin — Wed, 01 Jul 2026 02:30:00 +0200

I'm currently somehow or other writing a book, meaning that I'm spending a significant amount of time with markdown files open in my text editor, which happens to be (neo)vim. It's one of the least worst editors around, and I've been using it for more than 15 years I think. Unfortunately it doesn't have a great scripting language: vimscript is dreadful to read and equally dreadful to write, like an organic growth of a Perl tumor on top of a JavaScript teratoma on a perpetually dying swamp creature.

Anyway, the book currently has a bit less than 500 headings of various levels spread between ~20 chapters, making it non-trivial to keep them all in my head, meaning that I often wonders in what section the paragraph I'm writing is. So I took it upon myself to get dirty, and wrote a small snippet of vimscript to show me the current file's outline and my current position in it. It doesn't go out of its way to handle technically-valid-but-nobody-should-do-that markdown and is reasonably fast, taking around 7ms on a 20k lines/400 headings file on my machine. It should be compatible with neovim ≥ 0.10 and vim ≥ 9.1.0099, as the only modern construct it uses is the matchbufline function.

function! MarkdownOutline() abort
  if &filetype !=# 'markdown'
    echohl WarningMsg | echo 'Not a markdown file' | echohl None | return
  endif

  let l:cur_line = line('.')                                                 
  let l:cur_idx = 0                                                          
  let l:entries = []                                                         
  let l:is_fenced = 0                                                        
  for l:match in matchbufline(bufnr(''), '\v^%(#+ |```)', 1, '$')            
    let l:text = l:match.text                                                
    if l:text[0] ==# '`'                                                     
      let l:is_fenced = !l:is_fenced                                         
    elseif !l:is_fenced                                                      
      let l:line = getline(l:match.lnum)                                     
      let l:level = stridx(l:line, ' ')                                      
      let l:title = l:line[l:level :]                                        
      call add(l:entries, l:match.lnum . "\t" . repeat(' ', l:level - 1) . l:title)  
      if l:match.lnum <= l:cur_line                                          
        let l:cur_idx = len(l:entries)                                       
      endif                                                                  
    endif                                                                    
  endfor                                                                     

  if empty(l:entries)
    echohl WarningMsg | echo 'No headings found' | echohl None | return
  endif

  let l:options = ['--prompt', 'Outline> ', '--delimiter', "\t",
        \          '--with-nth', '2..', '--layout', 'reverse']
  if l:cur_idx > 0
    let l:options += ['--bind', 'load:pos(' . l:cur_idx . ')']
  endif

  call fzf#run(fzf#wrap('markdown-outline', {
        \ 'source':  l:entries,
        \ 'sink':    {l -> execute(matchstr(l, '^\d\+') . ' | normal! zz')},
        \ 'options': l:options,
        \ }))
endfunction

nnoremap <silent> <leader>o :call MarkdownOutline()<CR>

It looks like this:

It depends on fzf, to both show/filter the outline and quickly jump to whichever I want. Fortunately, it is packaged in most distributions, along with its thin vimscript wrapper that can be loaded like this:

for plugin_path in [
                        \ '/usr/share/doc/fzf/examples/plugin/fzf.vim',
                        \ '/usr/share/nvim/runtime/plugin/fzf.vim',
                        \ '/usr/share/vim/vimfiles/plugin/fzf.vim',
                        \ '/usr/share/nvim/site/plugin/fzf.vim',
                        \ ]
  if filereadable(plugin_path)
    exec "source" . fnameescape(plugin_path)
    nnoremap <C-p> :FZF<Cr>
    break
  endif
endfor

Now, I'm sure that there are plugins on GitHub doing all of this, but I'm averse to the idea of my editor downloading random code from the internet and executing it, sometimes as root.

Trivial anti-crawler with Caddy

jvoisin — Tue, 23 Jun 2026 13:45:00 +0200

With the internet being crawled to death to feed the AI God, it's becoming seriously annoying to exposed web content on the internet. While anubis works, it's yet another layer of complexity. It might be worth deploying and tuning it for high-profile websites, but for my cgit instance, it's absolutely overkill.

Instead, I'm taking advantage of Caddy (whose documentation doesn't have a search feature‽) matching capabilities to gate access on either the ability to execute javascript to set a cookie, or having a user-agent string starting with git/ so that repository are still cloneable.

git.dustri.org {
        import tls
        import noindex
        import compress

        @unverified {
                not header Cookie *not_a_crawler=1*
                not header User-Agent git/*
        }
        handle @unverified {
                header Content-Type text/html
                respond <<EOF
                    <script>
                    document.cookie = 'not_a_crawler=1';
                    window.location.reload();
                    </script>
                EOF 418
        }

        reverse_proxy cgit_upstream
}

It's not perfect, trivial to bypass, but strikes the right balance between simplicity/zero-maintenance and blocking crawlers. This technique is now used on https://autopkgtest.ubuntu.com.

Bloquer le spam téléphonique chez Free Mobile

jvoisin — Tue, 16 Jun 2026 23:00:00 +0200

This blogpost is in French, as it explains how to block spam calls for Free Mobile customers.

Le spam téléphonique fait partie de ces petites chose irritantes du quotidien dont on se passerait bien et qui continuent d'exister au mépris du bon sens. En attendant que la pratique soit rendue illégale et punie par une marche forcée sur de tout petits Lego, il est possible, via l'interface web de Free, de bloquer les plages de numéros utilisés par ces pénibles pour nous pourrir ledit quotidien.

L'ARCEP, louée soit-elle, publie une page détaillant le plan de numérotation téléphonique français, qui raconte en gros que "les prefixes 0162, 0163, 0270, 0271, 0377, 0378, 0424, 0425, 0568, 0569, 0948, 0949, 09475, 09476, 09477, 09478 et 09479 sont utilisés pour le démarchage".

Malheureusement, il reste des petits plaisantins qui utilisent d'autres numéros pour chagriner le quidam, souvent d'opérateurs qu'on pourrait charitablement qualifier de "peu regardant". Une solution tout à fait valide serait d'utiliser saracroche, une chouette application iOS/Android open-source qui permet de non seulement de bloquer les indésirables, mais également de collectivement constituer une base de données les recensant. Un petit passage par la documentation nous informe qu' "environ 15 millions de numéros sont bloqués, dont 12,5 millions correspondent aux préfixes réservés au démarchage téléphonique, communiqués par l'ARCEP". Plutôt que d'installer une nième application, on va utiliser son API pour aller récupérer quelques préfixes en plus de ceux de l'ARCEP. Comme la liste est conséquente, on va dégrossir par taille de plage :

$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("######"))' | wc -l
12
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("#####"))' | wc -l
20
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("####"))' | wc -l
253
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("###"))' | wc -l
1541
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("###"))' | wc -l
1541
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("##"))' | wc -l
1541
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern | contains("#"))' | wc -l
1541
$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators | jq -c '.patterns[] | select(.pattern)' | wc -l
1541
$

Je suis parti sur du #####, soit 100.000 numéros par blocage, en me réservant évidement la possibilité de descendre plus bas si cela s'avère nécessaire. Suivez votre cœur et prenez la granularité que vous voulez.

Un petit coup de jq/sed/tr d'une rare élégance pour mettre tout ça en forme:

$ curl --silent https://saracroche.org/api/v1/lists/french-list-arcep-operators \
    | jq -c '.patterns[] | select(.pattern | contains("#####")) | .pattern ' \
    | sed 's/^"33/"0/ ; s/#//g ; s/"$/*",/' \
    | tr '\n' ' '
"0162*", "0163*", "0270*", "0271*", "0377*", "0378*", "0424*", "0425*", "0568*", "0569*", "0948*", "0949*" "09475*", "09476*", "09477*", "09478*", "09479*", "07568*", "07569*", "07809*",
$

Pour bloquer tout ce joli monde, il suffit de se rendre sur https://mobile.free.fr/account/mes-services/filtres, et de coller le bout de JavaScript suivant dans la console du navigateur.

(async function () {
    var phonePatterns = [
        "0162*", "0163*", "0270*", "0271*", "0377*", "0378*", "0424*", "0425*",
        "0568*", "0569*", "0948*", "0949*" "09475*", "09476*", "09477*",
        "09478*", "09479*", "07568*", "07569*", "07809*"
    ];

    var saveUrl = '/account/mes-services/filtres?action=save';

    var existing = document.querySelectorAll('.f-rules__item--msisdn');
    var hasRule = p => [...existing].some(el => el.innerHTML.includes(p));

    for (const pattern of phonePatterns) {
        if (hasRule(pattern)) {
            console.log('Règle déjà présente: ', pattern);
            continue;
        }

        const body = new URLSearchParams({
            'rule-id': '',
            direction: '2',
            pattern: pattern,
            description: 'Spam',
            'full-day': '1',
            'full-week': '1',
            media: '1',
            action: '2'
        });

        const res = await fetch(saveUrl, {
            method: 'POST',
            headers: { 'Content-type': 'application/x-www-form-urlencoded' },
            body
        });

        console[res.ok ? 'log' : 'error']((res.ok ? '[OK]' : '[KO]'), pattern);
    }

    console.log('Toutes les règles ont été parcourues');
})();

fortify-headers 3.0.2

jvoisin — Sun, 10 May 2026 01:15:00 +0200

There is a new minor release of fortify-headers, namely 3.0.2. Minor releases means no new features, only bug fixes and improvements, mainly about portability regarding weird compilers. Oh and also a lot more tests. There are only 16 commits since the last release, so I think we can skip the proper changelog for this one.

Adoption-wise, Alpine Linux recently moved from 1.1 to 3.0.1, bringing FORTIFY_SOURCE=3 to all its users. The main goal is this release is to have fortify-header there, without any patches/fixes. We'll see how it goes.

As is now usual, the release is available on github, and the tag has been pushed on 2f30 as well.

Follow-up to Carrot disclosure: Forgejo

jvoisin — Thu, 30 Apr 2026 17:15:00 +0200

Since I published Carrot disclosure: Forgejo two days ago, numerous things happened:

Friends of mine were reached out to, to "talk to me from a place of trust", or simply to convey to them in great details what an horrible person I am, which they found hilarious.
The toot linking to the blogpost was removed from infosec.exchange by an overzealous moderator after it had been reported multiple times by multiple people. I thus moved to mastodon.social, where it was also removed with "Irresponsible disclosure" given as a reason. So I moved back to infosec.exchange, where the toot was restored. In the meantime, friends handed me invitations for various mastodon instances, which I'm grateful for.
Numerous instances of the eternal vulnerabilities disclosure debate spawned.
Some exploit-writer friends of mine complained that I brought unwanted attention to an easy target.
The Netherlands deployed a sovereign software forge in the form of a public forgejo instance.
Everyone had an opinion on mastodon on this, mostly on what I should do with the vulnerabilities I found, and was really vocal about it, especially people who aren't related to computer security. It seems that we're still in the "fixing bugs will make us more secure" era, which is a bit sad. I also, of course, got called a handful vile names.
The terms "not professional" (as in "not acceptable in a professional environment") has been thrown around a lot, but nothing here is or was being done in a professional context.
Forgejo's security policy was copiously made fun of.
I got a tone deaf email from Forgero's moderation team, to my arguably tone-deaf blog post, which I think is funny.
I've learnt that the role of Forgejo security team is to "take care of security vulnerabilities and to handle sensitive security-related issues reported to security@forgejo.org using encryption." Doing anything proactive isn't in their attributions.
Various entities, including some with security teams, revised their judgment about what Forgejo is and isn't, which was the main goal of the previous blogpost.

Nonetheless, some productive good faith conversations have been had as well, and it seems that experimenting with odd vulnerability disclosure schemes is frowned upon. So I ended up sending an email to Forgejo security team, containing: an apology, a bit about my reasoning for proceeding with carrot disclosure, recommendations about what to harden/review, and a bunch of commented exploits/proof-of-concepts as attachment. We'll see how it goes.

On a more personal note, I found the amount of flak and hate completely wild, and I think I would have got way less had I simply decided to go with full disclosure. Heck, even a "found cool bugs in Forgejo, sold them for peanuts lol" would probably have been better received. But as a friend explained to me: "everyone loves the puppy, but also knows how weak it currently is, and you kicked the puppy, yelling about how weak the fucker is.", which is an apt metaphor I guess.

And now, some out of context anonymous quotes on the topic, from friends and foes, taken from HackerNews, lobste.rs, LWN, Mastodon, Bluesky, and various IRC channels, ordered by length, for no other particular reasons than to add some colouring (and let's be honest, a bit of much needed comic relief) to this whole event:

epic

grim

yikes

nice flex

QUIT TROLLIN

insufferable

how much for the RCE?

that's total fucking bs

OP is absolutely a dick

nice finds on forgejo!!!

the fuck is wrong with you?

wow, what an awful behavior

lmao jvoisin I'm loving this.

why, just put in the pull request

It's one way to not make friends ^_^

they need some reflection rather than rage

Exciting, curious if codeberg is affected ✨️

i believe this is what they call -- "a dick move"

The biggest asshole "disclosure" I've seen in a while.

They will call you an asshole, but can't do anything about it.

I honesty want a refund on the 10 minutes I wasted reading this.

some noname lowlife decided to be a jerk about an RCE they found.

maybe try properly disclosing the vulns instead. food for thought

i really cannot understand what possibly possessed you to do this

If you are in infosec, that's a great guide on how not to do disclosure.

The author's attitude is so off-putting. What gives? Did Forgejo hurt you?

having been on both sides of the equation i kind of want to punch this guy

Doing things like this, especially against a volunteer-run project is a dick move.

At least tell them what you found and see if they fix it before choosing the asshole action.

Yes that reviewer is kind of a dick but the submitter just escalated to nuclear dick.

alright, took 6h to get a working RCE on forgejo, solid software, 10/10 would recommend deploying

As soon as i see that security policy i tune out. It's like one of those in game EULA no one reads

they should reread your followup blogpost, I feel like they misunderstood "a bunch of" for "all my"

putting end users and admins at risk by publishing clues about zero days just to show off is disgusting

https://codeberg.org/forgejo/website/issues/839#issuecomment-14208296 bullshit, my preauth RCE still works :')

Their motivation isn't making one tool better, but keeping users safe. We need those people and the work they do badly!

Appreciate that you looked into forgejo security. I can also see why you're writing style did "activate" a lot of people tho :)

My personal thought is that I appreciate, as a defender, knowing this information about a project having a systematic lack of security.

The policy is poorly worded. Most of those uppercase words should be "please". You don't get to require anything of security researchers.

That's an incredibly condescending way to talk about someone else's work, and a horrible attempt to force volunteers to follow your priorities.

I'm not really familiar with forgejo other than knowing vaguely about its history. I'm a little surprised it's so bad given its adoption though

trying to coerce people to fix bugs you don't feel are worth reporting properly by posting publicly is a dick move, whether the devs are paid or volunteers, imo

I really like the idea of forgejo, but as someone following the development channel, it really feels like FOSS hobbyist and not that much engineers maintaining a huge forge.

Outside of the diff not loading, because codeborg slow af, they want you to write a freaking js test for that? Like I understand how technically test that, but which value does it add?

Sadly there is no shortcut to "the whole thing stinks and I want to get people to stop using it". You might have thought you had one with the carrot approach but it also does not work.

this is an interesting disclosure strat, but I'm not sure i think its the best one to apply to foss. might be better used to pressure all the ivantis of the world to stop getting everyone owned.

i will point my coworkers at your research, it's a dutch entity. They might get the forgejo ppl going. Honestly the "did you write a test?" response on the xss hardening issues was a bit monty python level

Yo this person attitude is insane. I didn't saw the comment about mail those patches instead of opening PR They're fucking crazy. I opened one of your PR to see if there was new comments, I think it crashed codeberg.

Seems like grandstanding bad faith to me. They didn't even bother to follow the established disclosure policy for this project because the author feels this quality of the code is so crap, so instead does this...

It would definitely be a bit silly for the author to make a fake carrot disclosure, but I thought of it just because of how reading this article made me feel distrust toward the author. IDK, they just seem like kind of a jerk!

I think the person who did this did it only to have their moment of fame, and it apparently worked. I would personally have omitted their name from the description above to avoid further promoting such bad behaviors.

Getting HTML building right is a pretty basic building block of web apps, Forgejo can't have great security practices if they aren't doing that. So I can easily imagine the OP is correct in their assessment of Forgejo code security.

This is not okay. Trolling a FOSS project showing off a zero day instead of sending PRs or a proper security report... and the only justification given is that they didn't like a PR removing a feature, and haven't yet merged another PR opened yesterday??

that's bad. We are trying to build stuff together, as a community. What you're doing is basically kicking down the stuff other people have built. I'll be discussing that behaviour when we are considering our next donation to @nos_oignons.

I have security experience and hearing that there is these issues makes me want to contribute to forgejo, but I'm also discouraged from doing that, because of how much of an asshole you're being here. I don't want to give you what you want.

< snark >but I mean the alternative would've been to spend time reporting and maybe the developers wouldn't take you as seriously as you think you should be taken and that might hurt your feelings or require emotional labor to convince someone to look more broadly</ snark >

they seem to have a hard time deciding if they are a serious project or just a toy one that possibly couldn't be scrutinized because it's just a bunch of volunteers. Schrodinger's seriousness, very profession or very helpless depending on whatever's more convenient at the moment.

This seems like a pretty dick move without even attempting to engage with Forgejo first. A combination of assumptions based on no evidence and "I don't feel like it" is not a good look. They aren't a large company with money to burn, they depend on people being willing to pitch in or at least provide details before going nuclear.

You may ASK unpaid security research volunteers to participate in some coordinated disclosure, but you can't demand they surrender their free time beyond the report. The maintainers are NLnet funded, the security researcher is operating on goodwill. The bugs are still sitting unaddressed in the open, although there's a recent commit fixing token expiry.

The Forgejo disclosure process looked pretty simple and straightforward to me. The bold and all-caps words that bothered the author are just making sure you know how to disclose vulnerabilities safely without leaking zero-day exploits to a wider audience than necessary. I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.

what you've done here was below any reasonable standard of professional conduct, and also very strange to me. I'm an accessibility nerd and have recently begun digging into Forgejo's accessibility bugs. They do have a few, which to me was like "oh cool, it will probably be fun to work with them on these". Makes no sense to me as a specialist in solving a particular type of problem to build a brand as someone this publicly hostile to those you deem as having too much of that problem.

Carrot disclosure: Forgejo

jvoisin — Tue, 28 Apr 2026 22:40:00 +0200

Since Fedora moved from Pagure to Forgejo, I finally had an incentive to take a good look at Forgejo's security posture. The results aren't pretty to be honest: SSRF in a lot of places, no CSP/Trusted-Types, a bit of ghetto templating in javascript, cryptographic malpractices, overlooks in the authentication mechanisms (OAuth2, OTP, sessions/access handling, post-compromission recovery, …), a bunch of low-hanging DoS, some information leaks, various TOCTOU, … All in all, it took me one evening after work to find a good amount of vulnerabilities (adding to the one I got from looking at gitea at some point in the past), and chain some of them to obtain a full-blown RCE, some secrets leaks, a bunch of persistent account access, a handful of OAuth2 privesc, …

Fortunately (or unfortunately depending who you're asking), the RCE relies on open registration, and on a configuration option set to a non-default value (which is the case on some instances I've looked at, so nothing exotic), meaning that its selling value is pretty low/nonexistent. I could disclose the bugs to Forgejo, they even have a Security Policy, with a lot of MUST/MUST NOT about what I must or mustn't do should I decide to go this way. But given the sorry state of the codebase (not their fault though, they inherited the gitea/gogs ones), I'm pretty sure I could spend another evening and find another chain, and odds are that others have a bunch as well. I could try to fix the issues one by one myself and send pull-requests, but even if I wanted, this is a systemic issue, there is little point in playing endless wack-a-mole.

I discussed the conundrum with a friend of mine, and was told to put my money where my mouth is, and just go with carrot disclosure that I usually advocate for in this kind of situation:

Carrot Disclosure, dangling a metaphorical carrot in front of the vendor to incentivise change. The main idea is to only publish the (redacted) output of the exploit for a critical vulnerability, to showcase that the software is exploitable. Now the vendor has two choices: either perform a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability; or losing users who might not be happy running a known-vulnerable software.

So without further ado:

$ python3 ./chain_alpha.py --target http://127.0.0.1:3000 > out.txt
$ grep Backdoor out.txt 
[+]   Backdoor admin created: svc_ljeopgid / dukecepapsygiqks!A1
$ tail -n17 out.txt 

================================================================
[+] COMMAND EXECUTION CONFIRMED!
================================================================

Server-side hook output (received via git push stderr):

  remote: ==========================================
  remote: FORGEJO RCE PoC - Command Execution Proof
  remote: ==========================================
  remote: hostname: chernabog
  remote: uid:      uid=1000(jvoisin) gid=1000(jvoisin) groups=1000(jvoisin),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  remote: date:     Tue Apr 28 19:16:59 UTC 2026
  remote: proof:    chernabog
  remote: ==========================================

================================================================
$ sha256 ./chain_alpha.py
c10d28a5ff74646683953874b035ca6ba56742db2f95198b54e561523e1880d7  ./chain_alpha.py
jvoisin@chernabog 11:35 ~/Documents/exploits/forgejo tree
.
├── chain_alpha.py
├── chain_beta.py
├── chain_gamma.py
├── dos
│   ├── cpuburn_authenticated.py
│   ├── cpu_dos.py
│   ├── dbburn.py
│   ├── dfburn.py
│   ├── exhaust.py
│   ├── gburn.py
│   ├── grpstarve.py
│   ├── rstarve.py
│   ├── starve.py
│   └── storage.py
├── f9_repo_settings.py
├── get_version.py
├── leak_secrets.py
├── leak_token.py
├── merge.py
└── NOTES.md

2 directories, 19 files
$

[edit] you might be interested in the follow-up blogpost.

swic: a simple web interface for calibre

jvoisin — Tue, 21 Apr 2026 02:00:00 +0200

I'm ~regularly doing lightweight security audits of the services I'm running exposed on the internet. One of them is calibre-web. After 2h and 17 security-related pull-requests later, I gave up and decided to write a replacement: swic. It only has 3 user-facing features: showing the ebooks as a list, a searchsbar, and allowing the user to download the ebooks. I don't need anything else. UI-wise, it looks like this:

It's written in go, meaning that it's both trivial to deploy and to audit. It has a single direct dependency (modernc.org/sqlite) to read calibre's database. It doesn't handle users, doesn't need to have write-access to anything, doesn't process untrusted data besides user-provided urls, makes use of Go's os.root to prevent path traversals. The interface is fully responsive and doesn't use any javascript.

The code isn't the prettiest, but the whole thing was written in an evening. You should replace calibre-web with it before somebody drops an RCE :p

A quick look at __pledge_open(2)

jvoisin — Thu, 02 Apr 2026 14:30:00 +0200

A recent article of the OpenBSD journal caught me attention: Pledge changes in 7.9-beta (archive.org mirror as it's currently offline).

The quoted message starts with:

Previously under certain promises it was possible to open certain files or devices even if the program didn't pledge "rpath" or "wpath". This behavior has gone away in 7.9-beta; libc uses the special __pledge_open(2) syscall which cannot be used outside of libc.

So a new syscall, bypassing pledge/unveil, interesting. The "cannot be used outside of libc" is likely referring to pinsyscall, which is an indirect call away. Let's check if this is indeed a sandbox escape. The function setservent_r has a call to __pledge_open, so let's jump directly on the call to please pinsyscall:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <signal.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/ptrace.h>
#include <string.h>

#define F "/tmp/pwned.txt"

typedef int unrestricted_open(const char *, int, ...);

static void on_sigtrap(int sig, siginfo_t *si, void *ctx) {
    // Catch the int3 of setprotoent's epilogue function
    (void)sig; (void)si; (void)ctx;
    write(STDERR_FILENO, "caught SIGTRAP\n", 15);
    char out[20];
    int fd = 4;
    printf("Trying to read fd: %d\n", fd);
    if (read(fd, out, sizeof(out)) < 0 ){
        puts("can't read");
    } else {
        puts(out);
    }

    exit(0);
}

int main(int argc, char** argv) {
    unveil("/home/", "r");
    unveil(NULL, NULL);

    struct sigaction sa;
    memset(&sa, 0, sizeof(sa));
    sa.sa_sigaction = on_sigtrap;
    sa.sa_flags = SA_SIGINFO;
    sigemptyset(&sa.sa_mask);

    if (sigaction(SIGTRAP, &sa, NULL) == -1) {
        perror("sigaction");
        return 1;
    }

    int fd = open(F, O_RDONLY);
    printf("Got fd for open: %d\n", fd);

    open(F, O_RDONLY);
    // offsets for -current valid at 2026-04-02
    size_t daemon_addr = &daemon;
    // get the address of the call to __pledge_open in setprotoent
    size_t unrestricted_open_addr = daemon_addr - (0x00076980 - 0x000E0A07);
    unrestricted_open* unrestricted_open_fcn = (unrestricted_open*)unrestricted_open_addr;
    unrestricted_open_fcn(F, O_RDONLY);

    return 0;
}

Unfortunately:

openbsd$ clang ./test.c  && ./a.out
1 warning generated.
Got fd for open: -1
caught SIGTRAP
Trying to read fd: 4
can't read
openbsd$

This is because there is a check in the form of pledge_namei, with hardcoded paths:

/*
 * Need to make it more obvious that one cannot get through here
 * without the right flags set
 */
int
pledge_namei(struct proc *p, struct nameidata *ni, char *path)
{
    // […]

    /*
     * In specific promise situations, __pledge_open() can open
     * specific paths and ignores rpath, wpath, or unveil restrictions.
     */
    if (ni->ni_unveil & UNVEIL_PLEDGEOPEN) {
#ifdef SMALL_KERNEL
        /* To save ramdisk space, we trust the libc provided paths */
        ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
#else
        int item;

        item = checkpledgepaths(path);
        if (item == 0 &&
            strncmp(path, "/usr/share/zoneinfo/",
            sizeof("/usr/share/zoneinfo/") - 1) == 0) {
            const char *cp;

            item = PLEDGEPATH_ZONEINFO;
            for (cp = path + sizeof("/usr/share/zoneinfo/") - 2;
                *cp; cp++) {
                if (cp[0] == '/' &&
                    cp[1] == '.' && cp[2] == '.' &&
                    (cp[3] == '/' || cp[3] == '\0')) {
                    item = 0;   /* bad path */
                    break;
                }
            }
        }

        switch (item) {
        case 0:
            /* Invalid path provided to __pledge_open */
            return (pledge_fail(p, EACCES, (nip & ~ple)));

        /* "stdio" - for daemon(3) or other such functions */
        case PLEDGEPATH_NULL:
            if ((nip & ~(PLEDGE_RPATH | PLEDGE_WPATH)) == 0)
                ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
            break;

        /* "tty" - readpassphrase(3), getpass(3) */
        case PLEDGEPATH_TTY:
            if ((ple & PLEDGE_TTY) &&
                (nip & ~(PLEDGE_RPATH | PLEDGE_WPATH)) == 0)
                ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
            break;

        /* "getpw" requirements */
        case PLEDGEPATH_SPWD:
            /* XXX should remove nip check! */
            if ((ple & PLEDGE_GETPW) && (nip == PLEDGE_RPATH))
                return (EPERM);
            break;
        case PLEDGEPATH_PWD:
            /* FALLTHROUGH */
        case PLEDGEPATH_GROUP:
            /* FALLTHROUGH */
        case PLEDGEPATH_NETID:
            if ((ple & PLEDGE_GETPW) && (nip == PLEDGE_RPATH))
                ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
            break;

        /* "dns" requirements */
        case PLEDGEPATH_RESOLVCONF:
            /* FALLTHROUGH */
        case PLEDGEPATH_HOSTS:
            /* FALLTHROUGH */
        case PLEDGEPATH_SERVICES:
            /* FALLTHROUGH */
        case PLEDGEPATH_PROTOCOLS:
            if ((ple & PLEDGE_DNS) && (nip == PLEDGE_RPATH))
                ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
            break;

        /* tzset() often happen late in programs */
        case PLEDGEPATH_LOCALTIME:
            /* FALLTHROUGH */
        case PLEDGEPATH_ZONEINFO:
            if (nip == PLEDGE_RPATH)
                ni->ni_cnd.cn_flags |= BYPASSUNVEIL;
            break;

        default:
            panic("pledgepaths table is broken");
        }
#endif /* SMALL_KERNEL */
    }
// […]

Maybe it's worth reading emails in their entirety after all, instead of only the first paragraph, as it ended with:

The list of promises and the special paths which could previously be opened under that promise is:

stdio /dev/null (rpath or wpath) /etc/localtime /usr/share/zoneinfo

tty /dev/tty (rpath or wpath)

dns /etc/resolv.conf /etc/hosts /etc/services /etc/protocols

getpw /etc/group /etc/netid /etc/pwd.db (the .db files really should be left to the system) /etc/spwd.db (could not open, but returned EPERM)

For non-root users, this looks pretty solid. As a small consolation, it might still be a valid bypass on OpenBSD with a compiled with SMALL_KERNEL, but OpenBSD being what it is, -current doesn't compile with the SMALL_KERNEL option, and I can't be arsed to fix it:

openbsd# make
cc -g -Werror -Wall -Wimplicit-function-declaration  -Wno-pointer-sign  -Wframe-larger-than=2047 -Wno-address-of-packed-member -Wno-constant-conversion  -Wno-unused-but-set-variable -Wno-gnu-folding-constant -mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse -mno-3dnow  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding -fno-pie -msave-args -mno-retpoline -fcf-protection=none -Oz  -pipe -nostdinc -I/sys -I/usr/src/sys/arch/amd64/compile/GENERIC/obj -I/sys/arch  -I/sys/dev/pci/drm/include  -I/sys/dev/pci/drm/include/uapi  -I/sys/dev/pci/drm/amd/include/asic_reg  -I/sys/dev/pci/drm/amd/include  -I/sys/dev/pci/drm/amd/amdgpu  -I/sys/dev/pci/drm/amd/display  -I/sys/dev/pci/drm/amd/display/include  -I/sys/dev/pci/drm/amd/display/dc  -I/sys/dev/pci/drm/amd/display/amdgpu_dm  -I/sys/dev/pci/drm/amd/pm/inc  -I/sys/dev/pci/drm/amd/pm/legacy-dpm  -I/sys/dev/pci/drm/amd/pm/swsmu  -I/sys/dev/pci/drm/amd/pm/swsmu/inc  -I/sys/dev/pci/drm/amd/pm/swsmu/smu11  -I/sys/dev/pci/drm/amd/pm/swsmu/smu12  -I/sys/dev/pci/drm/amd/pm/swsmu/smu13  -I/sys/dev/pci/drm/amd/pm/swsmu/smu14  -I/sys/dev/pci/drm/amd/pm/powerplay/inc  -I/sys/dev/pci/drm/amd/pm/powerplay/hwmgr  -I/sys/dev/pci/drm/amd/pm/powerplay/smumgr  -I/sys/dev/pci/drm/amd/pm/swsmu/inc  -I/sys/dev/pci/drm/amd/pm/swsmu/inc/pmfw_if  -I/sys/dev/pci/drm/amd/display/dc/inc  -I/sys/dev/pci/drm/amd/display/dc/inc/hw  -I/sys/dev/pci/drm/amd/display/dc/clk_mgr  -I/sys/dev/pci/drm/amd/display/dc/dccg  -I/sys/dev/pci/drm/amd/display/dc/dio  -I/sys/dev/pci/drm/amd/display/dc/dpp  -I/sys/dev/pci/drm/amd/display/dc/dsc  -I/sys/dev/pci/drm/amd/display/dc/dwb  -I/sys/dev/pci/drm/amd/display/dc/hubbub  -I/sys/dev/pci/drm/amd/display/dc/hpo  -I/sys/dev/pci/drm/amd/display/dc/hwss  -I/sys/dev/pci/drm/amd/display/dc/hubp  -I/sys/dev/pci/drm/amd/display/dc/dml2  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/inc  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/src/dml2_core  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/src/dml2_dpmm  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/src/dml2_mcg  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/src/dml2_pmo  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/src/dml2_standalone_libraries  -I/sys/dev/pci/drm/amd/display/dc/dml2/dml21/src/inc  -I/sys/dev/pci/drm/amd/display/dc/mmhubbub  -I/sys/dev/pci/drm/amd/display/dc/mpc  -I/sys/dev/pci/drm/amd/display/dc/opp  -I/sys/dev/pci/drm/amd/display/dc/optc  -I/sys/dev/pci/drm/amd/display/dc/pg  -I/sys/dev/pci/drm/amd/display/dc/resource  -I/sys/dev/pci/drm/amd/display/modules/inc  -I/sys/dev/pci/drm/amd/display/modules/hdcp  -I/sys/dev/pci/drm/amd/display/dmub/inc  -I/sys/dev/pci/drm/i915 -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS -DSUSPEND -DHIBERNATE -DSMALL_KERNEL -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU -DI915 -DONEWIREVERBOSE -DMAXUSERS=80 -D_KERNEL -MD -MP  -c /sys/dev/acpi/acpibtn.c
/sys/dev/acpi/acpibtn.c:292:12: error: use of undeclared identifier 'pwr_action'
  292 |                         switch (pwr_action) {
      |                                 ^
1 error generated.
*** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC (Makefile:2680 'acpibtn.o')
openbsd#

So who knows.

(Thanks to K3 for looking into this with me.)

Quick notes on KERNSEAL

jvoisin — Wed, 25 Mar 2026 15:30:00 +0100

The mysterious unreadable kernseal.txt file on PaX' documentation page has been sitting there since 2003, described as "sealed kernel storage design & implementation." In 2006, it was described as:

the problem KERNSEAL sets out to solve is kernel self-protection, that is, assuming arbitrary read/write access to kernel memory (by some bug, but for all i care, it could even be a mode 777 /dev/mem as well), the goal is to prevent privilege elevation (vs. privilege abuse which is an even harder problem to solve).

After many years of KERNSEAL ETA WEN jokes on #grsecurity, it was finally made available to grsecurity beta customers in August 2023 and to LTS ones in January 2024. I was eagerly expecting minipli's blogpost on the topic, but since none got published so far, I endeavoured to read an old patch a friend of mine was kind enough to sling my way, and take/publish some high-level notes while waiting for it, as apparently the diff for pax-linux-6.2.13-test6-kernseal-only.patch is "only" 66 files changed, 1118 insertions(+), 361 deletions(-). Odds are that most of my understanding is completely wrong nonetheless, so take everything written here with a mountain of salt. Also, I took an old patch and left some bits out out of courtesy, as grsecurity isn't freely available anymore.

The main idea behind PAX_KERNSEAL seems to be the constification of dynamically allocated objects, a bit like PAX_CONSTIFY_PLUGIN is doing for static ones, as well as completely hiding some of them as well. It depends on a couple of things to enforce its security invariants:

PaX' RAP, to prevent existing code out-of-(intended)-order execution, otherwise an attacker could simply ROP their way around KERNSEAL.
PAX_PRIVATE_KSTACKS, to defend against kthreads manipulating each other return addresses after RAP checks.
CONFIG_PAX_PER_CPU_PGD, to prevent other kthreads from accessing temporarily unsealed pages on a given CPU.
CONFIG_PAGE_TABLE_ISOLATION, of course.
Not having hibernation nor kexec support.

It introduces two new page states via GFP flags, and stores those properties in the struct page:

__GFP_SEALED/PG_sealed: The page is mapped read-only in the direct map (the linear mapping of all physical memory.)
__GFP_HIDDEN/PG_hidden: The page is mapped invalid (completely unmapped) in the direct map, so contents can't be read or written through the normal direct-map address.

New corresponding migrate types (MIGRATE_SEALED and MIGRATE_HIDDEN) are added to the buddy allocator, ensuring that sealed and hidden pages are grouped together in dedicated pageblocks. Of course those types are non-mergeable, preventing the allocator from stealing sealed/hidden blocks for normal allocations.

When a pageblock is set up for sealed or hidden use, pax_setup_pageblock() walks the PMD entries in the direct map and applies pmd_wrprotect() (for sealed) or pmd_mkinvalid() (for hidden), followed by a TLB flush. After allocation, post_alloc_hook() verifies that page flags match the requested GFP flags (sealed pages must have PG_sealed, etc.), and updates per-node statistics (NR_SEALED, NR_HIDDEN).

As hidden pages have no valid direct-map mapping, the kernel needs a way to temporarily access them, which is done via pax_expose_page/pax_hide_page pair, a bit like KERNEXEC's pax_open_kernel/pax_close_kernel are doing to keep the kernel code read-only.

A dedicated KM_USER_SLOT is reserved for KERNSEAL kmap operations, and every kmap-related call is hooked: if the page is hidden, it goes through pax_expose_page() to create a temporary per-CPU mapping; if sealed, access is blocked entirely with VM_BUG_ON_PAGE_ALWAYS, dumping the page and calling BUG().

A new kmalloc cache type (KMALLOC_SEALED) is added, to allow the kernel to allocated sealed data on a lower granularity than page-level. Temporarily unseal capability (for initialization for example) is provided by pax_open_seal()/pax_close_seal(), which are simply wrappers around pax_open_kernel and pax_close_kernel.

The most obvious usage of KERNSEAL on the patch I have is on struct cred: The mutable fields (usage, rcu, non_rcu) are split into a separate struct cred_rw, while the cred structure itself is marked __mutable_const, with the rw portion being actually a pointer to separately-allocated mutable memory:

 */
 struct cred {                                                                       
-       atomic_long_t   usage;
+       struct cred_rw {
+               /* RCU deletion */
+               union {
+                       int non_rcu;            /* Can we skip RCU deletion? */
+                       struct rcu_head rcu;    /* RCU deletion hook */
+               };
+#ifdef CONFIG_PAX_KERNSEAL      
+               struct cred     *cred;
+#endif
+               atomic_long_t   usage;   
+       }
+#ifdef CONFIG_PAX_KERNSEAL
+       *rw;
+#else
+       _rw;
+#endif

// [...]

+#ifdef CONFIG_PAX_KERNSEAL
+} __randomize_layout __mutable_const;
+#else
 } __randomize_layout;
+#endif

and used like this:

+#ifdef CONFIG_PAX_KERNSEAL
+#define to_cred_rw(cred)       (cred->rw)
+#define to_cred(cred_rw)       (cred_rw->cred)                          
+#else
+#define to_cred_rw(cred)       (&cred->_rw)
+#define to_cred(cred_rw)       (container_of(cred_rw, struct cred, _rw))
+#endif
+

This means the credential's security-sensitive fields (UIDs, GIDs, capabilities) live on sealed pages and cannot be tampered with, while the reference count and RCU linkage live on normal writable memory.

Debugging-wise, When a page fault occurs on a direct-mapped address, the fault handler checks whether the page is sealed or hidden and provides a clear diagnostic:

+   if (is_direct_mapped_addr((void *)address)) {
+       struct page *page = virt_to_page((void *)address);
+       if (PageSealed(page) || PageHidden(page)) {
+           pr_alert("BUG: unable to handle page fault for %s page at %pS\n",
+               PageSealed(page) ? "sealed" : "hidden", (void *)address);

Moreover, sealed and hidden page counts are exposed via /proc/meminfo and per-node meminfo, plus per-process stats in /proc/<pid>/smaps:

Sealed: — total sealed pages in kB
Hidden: — total hidden pages in kB

New kpageflags bits (KPF_SEALED = 62, KPF_HIDDEN = 63) are also exported.

As for PAX_PRIVATE_KSTACKS (in the context of PAX_KERNSEAL), it creates a per-CPU page table where each task gets a dedicated slot with guard pages. Only the current task's stack is accessible, via dynamic PTE-level (un)mapping magic. Underlying physical pages are allocated with __GFP_HIDDEN of course. For stack variables that require DMA/async access, an ad-hoc GCC plugin identifies them and stores them in a per-task dedicated page.

Even though PAX_PRIVATE_KSTACKS and PAX_KERNSEAL are conceptually simple mitigation, they are likely super-tedious to apply to the Linux kernel code behemoth. Tackling data-only attacks is hard, and the only other people seriously trying to address them is Apple, with their hardware-based KTRR/CTRR/GXF/APRR/PPL/SPTM/TXM mitigations. This makes KERNSEAL all the more remarkable, as like everything produced by the PaX Team, it doesn't require special hardware support.

Another interesting property of KERNSEAL is that it can serve as a basis for other interesting things, like ensuring that no guest pages are available at the hypervisor level in KVM for example. I can't wait to see what will be built on top next.

All in all, unsurprisingly, KERNSEAL is yet another all-around tour de force from the PaX Team, who keeps consistently producing stellar software-only mitigations before everyone else, since almost 25 years.

Fixing Steam's "Download failed: http error 0" on Asahi Linux

jvoisin — Wed, 18 Mar 2026 00:45:00 +0100

Thanks to the amazing work of the Asahi Team, Steam is running on my arm64 Linux on my Apple M2. Unfortunately, it seems that a recent update broke the ability for Steam to speak to the internet, with logs looking this like:

[2026-03-17 23:11:20] Set status message: Checking for available updates...
[  0%] Checking for available updates...
[2026-03-17 23:11:20] Set percent complete: -1
[2026-03-17 23:11:20] Manifest download: waiting for download to finish
[2026-03-17 23:11:20] Manifest download: finished
[2026-03-17 23:11:20] Download failed: http error 0 (client-update.fastly.steamstatic.com/steam_client_ubuntu12)
[2026-03-17 23:11:20] Downloading manifest: https://client-update.akamai.steamstatic.com/steam_client_ubuntu12
[2026-03-17 23:11:20] Manifest download: send request
[2026-03-17 23:11:20] Manifest download: waiting for download to finish
[2026-03-17 23:11:20] Manifest download: finished
[2026-03-17 23:11:20] Download failed: http error 0 (client-update.akamai.steamstatic.com/steam_client_ubuntu12)
[2026-03-17 23:11:20] Downloading manifest: https://client-update.steamstatic.com/steam_client_ubuntu12
[2026-03-17 23:11:20] Manifest download: send request
[2026-03-17 23:11:21] Manifest download: waiting for download to finish
[2026-03-17 23:11:21] Manifest download: finished
[2026-03-17 23:11:21] Download failed: http error 0 (client-update.steamstatic.com/steam_client_ubuntu12)
[2026-03-17 23:11:21] DownloadManifest - exhausted list of download hosts
[2026-03-17 23:11:21] failed to load manifest from buffer.
[2026-03-17 23:11:21] Failed to load manifest
[2026-03-17 23:11:21] Error: Download failed: http error 0
[2026-03-17 23:11:21] Saving metrics to disk (/home/jvoisin/.local/share/Steam/package/steam_client_metrics.bin)
[2026-03-17 23:11:21] Verifying installation...
[2026-03-17 23:11:21] Verifying all executable checksums
[2026-03-17 23:11:21] Set percent complete: -1
[2026-03-17 23:11:21] Set status message: Verifying installation...
[----] Verifying installation...

A quick look at journalctl shows that SELinux doesn't like what passt is trying to do:

Mar 17 23:07:26 chernabog audit[2093303]: AVC avc:  denied  { execstack } for  pid=2093303 comm="passt" scontext=unconfined_u:unconfined_r:passt_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:passt_t:s0-s0:c0.c1023 tclass=process permissive=0

Passt is a piece of software providing user-mode networking for virtual machines, and apparently got stuck in the 90s because it requires an executable stack, sigh.

The easiest way to fix this is to ~~read the ~250-pages long SELinux notebook~~ use ausearch and to throw its output to audit2allow:

# ausearch -c 'passt' --raw | audit2allow -M local-passt
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i local-passt.pp

# cat local-passt.te

module local-passt 1.0;

require {
    type passt_t;
    class udp_socket getattr;
    class process { execmem execstack };
}

#============= passt_t ==============

#!!!! This avc is allowed in the current policy
allow passt_t self:process execstack;
allow passt_t self:process execmem;

#!!!! This avc is allowed in the current policy
allow passt_t self:udp_socket getattr;
# semodule -i local-passt.pp
libsemanage.semanage_direct_install_info: Overriding local-passt module at lower priority 300 with module at priority 400.
#

And that's it, Steam should now be able to reach the information superhighway again.

"Have I Been Stalked" post-mortem

jvoisin — Wed, 11 Feb 2026 00:30:00 +0100

With more and more databases from stalkerware being made freely available, there were some internal conversations at Echap about what could be done with them to help victims. Everyone knows Have I Been Pwned, the website where you can put your email address and check if it appears in popular database leaks. Wouldn't it be nice to do something similar, but for stalkerware?

I built a prototype in Flask, but quickly switched to Django because of its autogenerated administration interface. It also comes with a lot of nice things like a declarative data model, integrated form validation, and so on. For the database, PostgreSQL was suggested, but I picked sqlite instead, as not that much traffic is expected, and except for new leaks incorporation, access will be purely read-only. Also, easy backups. To prevent enumeration/bruteforce and to keep bots in check, hcaptcha is alright, and it'll likely have a better accessibility than something homegrown.

The real questions were more about privacy than about the technical stack. First of all, the decision was made of allowing users to query the database via IMEI, and not phone numbers, since the later is usually public, and we don't want anyone to check their friends devices. Another important piece was data minimization: we already have databases with a ton of data in them, and there is nothing we can do to reduce those, but what we can do is to only put the smallest possible subset of this data on the website, to tell people if their device was infected, when, by what, and possibly by whom.

The IMEI is stored hashed, not for security purposes as the number of possible IMEI is around 10¹⁴ making the whole keyspace absolutely bruteforceable, but so that an administrator doing maintenance/debugging doesn't see them in clear-text. Another nice trick to prevent the website from knowing who is checking what device, is to generate a dozen random IMEI client-side, and send them along with the real IMEI the user is checking, so that it could only be inferred, if someone wanted to look after the fact, that a given IP address checked a given set of IMEI. Of course, the IMEI-checking queries are made via POST, and thus don't show up in the logs.

Speaking of data, the database leaks were either publicly available, or sent to us by third parties. There is no plans to share them with anyone.

While I'm the one who wrote the code, this project is also the brainchild of Esther, who provided technical expertise on " Django and stuff in production", back'n'forth conversations on everything privacy-related, as well as an early Django-based prototype.

The website looks like this:

Now where can you find this marvel of modern engineering? Well you can't (albeit I can provide the code if you really want.) It was eventually decided to not go through with the project for several reasons, including:

It's a legal minefield that Echap, as a miniscule non-profit, isn't equipped at all to navigate.
On haveibeenpwned, the remediation steps are straightforward: change your password, email you national data protection authorities, go on with your life. For stalkerware, not so much; it's a traumatic event to be told that one's phone has been spied on, and removing the stalkerware might tip the attacker and worsen the situation. Moreover, Echap's is only providing technical expertise/support/training/documentation to entities doing actual assistance, not the assistance itself.
While I'm more-or-less confident in my technical skills, hosting such sensitive data on the internet makes is the kind of thing that keeps you up at night.

It was an interesting idea, with exciting privacy challenges, but in the end, I'm glad it was shelved. But rest assured that other things have being worked on ;)

Antide's Law

jvoisin — Wed, 04 Feb 2026 21:00:00 +0100

A friend of mine, namely Antide "xarkes" Petit, came up with a pretty good rule of thumb that I think should be elevated into a law, Antide's Law:

If it's unclear what a cyber-security company is doing, what they're doing is pretty clear.

For example, take a look at Offensive Con 2025 and 2024 sponsors. Amongst them, you can find:

Catalyst Security: "Catalyst Security is a growing team of highly experienced vulnerability researchers, working on solving the most challenging problems in support of our customers."
SAFA: "Leveraging human and machine intelligence, SAFA zooms into cyber threat flashpoints, keeping you protected now and into the future." as well as "SAFA’s progressive approach to cybersecurity means we’re not content to see clients tread water; we strive to keep them ahead of cyber threats. Our in-house research, along with the latest technologies, lets you see what’s coming and proactively adapt."
Vigilant Labs: "It's a need to know thing."
Binary Gecko: "Binary Gecko GmbH provides tailor made cybersecurity solutions and services. Our international team is made up of world class, highly technical professionals with a proven track record in the field. We strive to tackle every problem with a holistic and in depth approach."
Secfence: "Secfence has been the pioneer of Information Security in India for almost a decade. We are a research- based organization and we take pride in innovating and pioneering many techniques and methodologies in Information Security. Along with our in-house research teams, we have formed global alliances to bring the latest and the best technology to our clients."

It's not obvious what services those companies are providing, so it's pretty obvious what services they're providing: exploits/capabilities.

Of course, it isn't a universal law. For one, it doesn't apply to megacorporations, as they too tend to have meaningless blurbs on their websites as well. For example, while "Capgemini helps businesses imagine their future and make it real with AI, technology and people." doesn't means much, what they're providing is information technology consulting and outsourcing, like providing skip tracing services for enforcement and removal operations for the ICE. Also, sometimes, it's simply a company being abysmally bad at marketing.

Note that the contrapositive isn't true, a minority of companies are pretty open about what they're doing, like CrowdFense or Epsilon. And finally, some companies like Zerodium are so (in)famous that everyone knows more or less what they're doing.

Snuffleupagus 0.13.0 - Elephas

jvoisin — Wed, 07 Jan 2026 12:00:00 +0100

I just published a new release of Snuffleupagus, the hardening module for php7+ and php8+, version 0.13.0, codename "Elephas", named after the genus of elephants. There aren't any new flashing features, only bug fixes, PHP85 support, minor improvements, and a security fix for CVE-2026-22034!

Thanks to Thomas Chauchefoin for finding the vulnerability and producing a comprehensive write-up. While being assigned CVE is never fun, it's also a sign that people are interested in your software enough to spend the time to looks for bugs. Moreover, I guess it was a learning opportunity to be on the other side for once. As usual, the CVSS score (9.2/10) is bullshit by design as there is no way to properly account for the required conditions:

Snuffleupagus' upload_validation to be enabled, which isn't the default configuration.
To be manually configured to use vld.
To have the vld module unavailable.

Nevertheless, as PHP isn't erroring out on missing modules (!), whatever update/change breaking vld might silently result in a catastrophic remote code execution, so please do update. The fix is dead-simple and can easily be backported if that's your kink.

Changelog

Compatibility with PHP8.5
Add the possibility to log to a file
Improve .drop() logging reliability when set_error_handler is used
Improve simulation mode for unserialize() when no HMAC key is provided
Fix a possible arbitrary code execution on misconfigured upload_validation deployments (CVE-2026-22034)

As usual, if you want to help, we have some low hanging fruits ♥

See you in your PHP stack!

fortify-headers 3.0.1

jvoisin — Mon, 05 Jan 2026 17:30:00 +0100

There is a new minor release of fortify-headers, namely 3.0.1. Minor releases means no new features, only bug fixes.

The C language doesn't really have the notion of namespaces: all symbols, except those marked as static are exposed. To mitigate the possibility of collisions, it's a good practise to prefix exported symbols with an library-specific identifier, like xml for libxml2 (eg. xmlReadFile), SSL for OpenSSL (eg. SSL_library_init) and so on. Symbols starting with an underscore followed by either an upper-case letter or another underscore are implementation-reserved. I was a bit cocky, and assumed that since fortify-headers is kind of part of the implementation, I could name macros __format, __warning_if, __access, … Unfortunately, this lead to a collision with LLVM's libcxx, as it defines a __format macro in its C++ locale header (/usr/include/c++/v1/locale). This was found by Haelwenn (lanodan) Monnier, when he tried to make use of fortify-headers on Gentoo. The fix is quite straightforward: make use of a fortify-headers specific prefix, resulting in __fortify_format, __fortify_warning_if, __fortify_access.

The release is available on github, and the tag has been pushed on 2f30 as well.

2025 in retrospect

jvoisin — Wed, 31 Dec 2025 23:59:00 +0100

In 2025, I did, amongst other things:

Read some books:
- Torture Taxi: On the Trail of the CIA's Rendition Flights
- Outlaws Inc: a lot of storytelling, not much meat, still interesting.
- Boniments: hard to find anything hiding under so much sarcasm.
- The Assassination Complex: drone-powered war crimes made in USA.
- The Catcher in the Rye: anyone who wants to ban this book didn't read it.
- Blank Spots on the Map: The Dark Geography of the Pentagon's Secret World: fascinating.
- How to Argue With a Meat Eater (and win every time: the amount of bullshit the author had to deal with is impressive.
- Art Crime and its Prevention: A Handbook for Collectors and Art Professionals, equally boring and cocky, gave up around the middle of it.
- Breaking Things at Work: The Luddites Are Right About Why You Hate Your Job, trying to shove everything through a Marxist lens, felt tedious.
- A handful of manga:
  - Gantz: didn't age very well.
  - Deadman Wonderland, uninteresting, gave up after 6 tomes.
  - D.Gray-man: great drawings, everything else is tedious, gave up around book 10.
  - Kokō no Hito: great topic, terrible realisation on every level, gave up after 4 tomes.
  - Mashle: Magic and Muscles: something like "Harry Potter, but the dude can't do magic and has muscles instead." Refreshingly funny.
- Some Warhammer 40,000:
  - Planetkill, nice bunch of novellas.
  - Darkness in the Blood: Mephiston-wanking
  - Elemental Council: properly written Tau novel.
  - Angron: Slave of Nuceria, the birth of Angron's tragedy.
  - Khârn: Eater of Worlds, Khârn's post-Heresy comeback.
  - Ordo Sinister: short story about the eponymous Ordo Sinister
  - No Good Men: great Warhammer Crime short stories anthology
  - Steel Tread, a tank commander story wrapping up a planetary war, really nice.
  - Day of Ascension: a novel from the point of view of a Genestealer cult, refreshing.
  - Leviathan: Space Marines against Tyranids trying to save the day on a dying planet.
  - The Oubliette: with a Planetary governor balancing on the edge of heresy, really good.
  - Scions of the Emperor: Horus Heresy's Primarchs short stories anthology, pretty great.
  - Interceptor City: yet another chef d'œuvre by Dan Abnett featuring the Imperial Navy.
  - The Silent King: wrapping up the Dawn of Fire series, nice to read the Imperium lose for once.
  - Blood of the Emperor: anthology of small novellas about the Primarchs, some are great, others less so.
  - Angron: The Red Angel, about the crushing of a World Eater leader's dreams thanks to Angron's return.
  - The King of the Spoil: commoners fomenting a civil war, with nested political and judicial points of view.
  - Oaths of Damnation: bolter porn featuring the Exorcists chapter, with a terrific intro and a terrible ending.
  - Deathworlder: great Astra Militarum novel, with properly written, badass and charismatic female protagonists.
  - Urdesh: The Serpent and the Saint and Urdesh: The Magister and the Martyr, nice to see ocean-themed marines.
  - Daemonhammer: a novel about an unsubtle inquisitor, nice but not groundbreaking, characters felt a tad undeveloped.
  - Execution Hour, great book about the end of a Planet told by a vessel of the evacuation fleet, too bad the end felt rushed.
  - Era of Ruin: an anthology of novellas about what happens after The End and the Death, unfortunately none of them were super-memorable.
  - Hand of Abaddon, always nice to see the setting moving forward, even though the novel was a tad too tedious/scattered all around the place for my taste.
Did a couple of job interviews:
- Synacktiv, for a red team tooling developer position. I passed the (fun) technical challenge, but didn't finish the interview process as I signed elsewhere.
- The Wikimedia Foundation, for a Staff Software Security Engineer position. I got an offer that I declined, as I got a better one by another company 30min after getting this one.
- ███████████, for a Head of Security and IT position, which was remote-but-a-couple-of-days-a-week-in-Paris, managing 1.5 juniors, for around 3 times less than my current salary. The phone call was awkward.
- Zellic, for a security researcher position, but my solidity auditing skills were too weak, and I thus failed the really cool hiring challenge. But they offered me to continue the interview process for a software engineer/sysadmin position instead. I didn't give it a try it, as I already signed elsewhere.
Played some video games:
- On a computer:
  - A bit of Space Marines 2
  - Darktide, mostly with the 2 new classes.
  - Clair Obscur: Expedition 33, usually not a big fan of JRPG, but this game is nothing short of amazing.
  - Age of Wonders 4: great 4X game, which while not being my favourite genre at all, was a ton of fun.
  - Witchfire: hands down the FPS of the year for me. Great setting, great gameplay, visually astonishing, and a complete and utter lack of bullshit DLSS.
  - Mutant Year Zero: Road to Eden, a chill post-apocalyptic variant on XCOM, without the tedious base-building parts and with some neat stealth element.
  - Ready or Not: the spiritual successor to SWAT 4, but felt unfortunately a bit clunky and unfinished. Moreover, it unfortunately felt like another "kill the bad guys!" game, instead of playing a law-abiding officer.
- On a glorious steam deck:
  - Inscryption, gave up after the first act.
  - Balatro, great game, but too much luck involved for my taste.
  - The Precinct, I'm usually not a big fan of cops™, but playing GTA2 from the point of view of one, with proper penalties for not following due process is surprisingly nice.
Listened to some music.
Attended some concerts:
- The Svinkels!
- Alcest and BRUIT ≤, with the latter being a really good surprise.
- No One is innocent Fractal Universe Les tambours du bronx (opened with Sepultura's Bloody Roots, and closed with Rob Zombie's American Witch!), and Shaârghot, as the Boksons festival. Oh and we sung along while going back to the car on Early Maggots playing some classic Spliknot tracks in the distance.
Contributed to a couple of projects:
- metasploit and metasploit-payloads.
- miniflux, with around 200 (!) pull-request merged this year alone.
- harper, a trivial low-hanging things to make debugging easier, and opened a bunch of bugs.
- Alpine Linux, by being a package maintainer, sending a handful of merge-requests, and trying to get rid of python-six.
- Nos oignons, as part of the administration council and the sysadmin team. We're now responsible for a little bit more than 3% of the network's total capacity.
- OpenMW, by maintaining the infrastructure. MediaWiki, that we're using for our wiki, is not only annoying to keep up to date, but also to fight spam: doing SQL by hand isn't really state of the art abuse remediation, sigh. Let's hope that the combination of hCaptcha, DNSBL from spamhaus.org/spamrats.com/0spam.org/z.mailspike.net, keyword-based blocklist, and clownflare will curb the tide. And because morons can't stop externalizing their costs directly into our faces, I deployed Anubis on the forum and the wiki, sigh.
Kept on writing my book, reaching a bit more than 100.000 words.
Went to the Grehack, where I saw old friends and made new ones.
Added possible subtitles to this blog, bringing their total number above 1500.
Changed the TLS certificates for this website to use elliptic curves for the whole chain: enjoy marginally faster handshakes and equally marginally size reduction in certificates transmission!
Bought a house in the East of France, feel free to come say hi. As a side-effect I learnt how to do some basic plumbing/electricity/wood-working/gardening/…
Got a fully-remote job at Casaba Security. The first weeks were a bit odd for everyone, as the switch from from a megacorp to a small(er) structure was a bit rough, but in the end I'm quite happy working there.
Spent a couple of months without internet at home, hence why this little corner of the internet was unreachable. Things are now back to normal, and I have fiber in my office. A big thank you to everyone who reached out to enquire if everything was alright <3.
As part of a conscious effort to make the word a better and more welcoming place, I successfully changed my usage of expletives and insults to more inclusive ones. I also think that this provides a positive influence on my friends and family, leading by example. Newly used terms include "sac à merde" ("shitbag"), "va te faire cuire le cul" ("go get your ass cooked"), "va marcher sur des legos" ("go walk on legos"), "bête à bouffer du grillage" and "bête à bêcher de la flotte" ("wire-mesh-eater/water digging level of stupid"), … Do let me know if you have suggestions, I'd love to expand my range of possibility and nuances.

Fixing the health and safety video loop during the Oculus Quest setup

jvoisin — Tue, 23 Dec 2025 14:45:00 +0100

I gifted an Oculus Quest (that I got as a gift a couple of years ago) to my brother, but because we're in 2025 and everything computer-related sucks, one has to associate an online account with the device to make use of it. Imagine having to do this to use a regular screen… Nevertheless, if you're trying to factory-reset it and re-setup it, you'll end up having the (mandatory) "health and safety video" stuck in a loop and you won't be able to finish the process. This is because ~~Facebook~~ Meta is a small underfunded independent software company, and thus it sadly can't afford to make sure that a $500 product sold 5 years ago can still be setup today. If you're foolish enough to call the support, you'll likely be politely told to fuck off, so don't bother.

But I remember that when I played with it, the setup phase was trivial: odds are that an upgrade of the (mandatory for setup) android app broke compatibility with the device. Using an old version will likely work. Unfortunately, as Google's Play Store doesn't allow one to install older versions, for SeCuRiTy ReAsOnS. So instead of being able to download what we're looking for from a trusted source, we'll have to use something like uptodown to download the APK we're looking for, sigh. I picked the Oculus Quest 276.0.0.15.109, and it worked for me. Don't forget to click the "all variants" button on uptodown to pick the right architecture (arm64-v8a or armeabi-v7a). If you don't know which is the right one, don't worry: if you pick the wrong one, your phone will tell you that it can't install it, and you'll simply have to install the other one. Oh and also click ignore when it prompts you to upgrade to a newer version when you're using the app. Try to setup the Oculus quest again, and you should no longer be blocked on the annoying video.

Once the headset is setup, the application can be updated to its latest version in the Google Play Store, but you can remove it from your phone all the same since it's not needed once the setup is complete. Odds are that having anything Meta-related installed on your phone will give you cyber-cancer, steal your nudes and sell every pieces of information it can collect to the everyone willing to buy them, but you do you.

If you're worried about installing random APK files from the interweb (as you should), the file has been uploaded to VirusTotal, and is signed by the certificate 331660b6dd3bd582f3dfd3cbae4546724668a021, which is a correct Facebook one.

Oh, and since it's Christmas time, I'd recommend gifting Half-Life: Alyx to go with the device, it's a great game.

fortify-headers 3.0

jvoisin — Mon, 08 Dec 2025 17:00:00 +0100

In late 2022, I started to contribute to fortify-headers, and the original author, sin, was kind enough to entrust the project to me.

Unfortunately, I feel that I haven't lived up to the expectations, both from others, but also mine. I enthusiastically piled more code on top of it, instead of moving slowly and making sure that I wasn't breaking anything. Sure, I added a test suite, but it can't cover every edge-cases, especially when dealing with code used system-wide in virtually all C packages/software. It also didn't help that I had a "complicated" life those last couple of years.

Now onto the good news: I now have some peace of mind and free time again, meaning I can go back to try to properly maintain fortify-headers. I shelved everything I added to it on an experimental branch (so that nothing is lost, including old releases that I did), and started clean on top a sin's latest master again. I'm not happy about rewriting history, I think it was least worse option in my opinion, versus having a big "revert" commit, or an interminable daisy-chain of revert.

So what's new in this release 3.0 compared to sin's version? A handful of things:

A complete testsuite, running on github actions, with -Wall -Wextra
Clang support, thanks to q66
access and format annotations
A missing include in select.h was added
wctomb was removed, as it was buggy
Support for swab was added
a 64b fix for time

Attribution was of course kept, and everything is available on https://git.2f30.org/fortify-headers/log.html and https://github.com/jvoisin/fortify-headers (to use github CI). QA-wise, on top of the testsuite, a full OpenWRT build is used as a smoke test. This should prevent bugs from creeping in.

I'd love if people of you could take a quick look at this new tentative, so that I can ask downstream projects to give a new try at upgrading from 1.1.

Running the packaged *arr stack on Alpine

jvoisin — Thu, 04 Dec 2025 00:15:00 +0100

I've been running some parts of the *arr stack on my hypervisor at home for quite some time now, but only recently did I notice that they were packaged in Alpine! I trashed the container with all the carefully-deployed-by-hand binaries, created a new one running Alpine Edge, ran apk add sonarr radarr prowlarr, and…

~ # apk add sonarr radarr prowlarr
ERROR: unable to select packages:
  aspnetcore6-runtime (no such package):
    required by: sonarr-4.0.16.2944-r0[aspnetcore6-runtime]
~ #

Urgh, the latest Sonarr release (v4.0.16.2944), is still running on .NET 6, which isn't packaged anymore on Alpine Edge. Fortunately, one can do horribly unsupported things like mixing repositories, and have a /etc/apk/repositories frankenfile looking like this:

https://dl-cdn.alpinelinux.org/alpine/edge/main
https://dl-cdn.alpinelinux.org/alpine/edge/community
https://dl-cdn.alpinelinux.org/alpine/edge/testing

@main319 https://dl-cdn.alpinelinux.org/alpine/v3.19/main
@community319 https://dl-cdn.alpinelinux.org/alpine/v3.19/community

Installing Sonarr can then be done with apk add sonar@community319 sonar-openrc@community319, launched via service sonarr start, and … it crashes after a couple of seconds. Running service -d sonarr start tells us that the binary being launched is /usr/lib/sonarr/bin/Sonarr, so let's see what happens when we run it manually:

~ $ /usr/lib/sonarr/bin/Sonarr
You must install or update .NET to run this application.

App: /usr/lib/sonarr/bin/Sonarr
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.36' (x64)
.NET location: /usr/lib/dotnet

The following frameworks were found:
  6.0.31 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
  8.0.22 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.36&arch=x64&rid=alpine.3.23-x64&os=alpine
~ $

Alright, .NET version mismatch: we have 6.0.31 installed and the binary wants 6.0.36. The DOTNET_ROLL_FORWARD environment variable can be used to make a binary run on newer version of the runtime, but not an older one. While we can't use 6.0.31, we have 8.0.22 installed for the rest of the *arr stack, so let's give it a try. Adding DOTNET_ROLL_FORWARD=LatestMajor followed by export DOTNET_ROLL_FORWARD in /etc/init.d/sonarr does the trick, and Sonarr is now working, huzzah!

Once Sonarr 5.X is released, I'll simply remove the @community319/@main@319 lines from /etc/apk/repositories and run apk update; apk upgrade to get the version compiled for modern packaged .NET.

IPv6 with a Freebox Pop and OPNSense

jvoisin — Sun, 30 Nov 2025 15:00:00 +0100

Because the Freebox Pop is ~~an underpowered piece of crap~~ quite weak when it comes to NAT'ing anything above 100Mbps, I decided to get a proper machine and slap OPNSense on it: I'm paying for the whole fiber, I'm going to use the whole fiber.

IPv4 was trivial: Firewall -> NAT -> Port Forward, and you're done. It took me 5 minutes. IPv6 very much not so, partly because I don't have a clue about IPv6 (and let's be honest, network in general), partly because it's an almost 30 years old pile of designed-by-committee RFC.

Amyway, the Freebox Pop is giving me seven /64 prefixes that I can freely delegate, so for simplicity's sake and because I'm a lazy punk, I:

~~waste~~ use one for the network between the Freebox and the WAN interface of OPNSense.
use a second one for the LAN

It looks like this:

+──────────+
│ Internet │
+──────────+
     │
     ▼
┌─────────┐
│ Freebox │
└─────────┘
     │      prefix A
     ▼
┌──────────┐
│ OPNSense │
└──────────┘
     │      prefix B
     ▼
  +─────+
  │ LAN │
  +─────+

Apparently, it's possible to not waste a prefix for the network between the Freebox and the router, but in the spirit of modern times, I'm comfortable wasting a significant amount of resources because I couldn't be bothered.

Freebox side

Open http://mafreebox.freebox.fr in your browser
Paramètres de la Freebox -> Réseau Local: Mode Réseau -> Bridge
Open http://mafreebox.freebox.fr in your browser
Paramètres de la Freebox -> Connexion Internet: Configuration IPv6
1. Note the Local link address
2. Note the first and second delegate prefixes, eg. 2a01:xxx:xxx:xxx1:: and 2a01:xxx:xxx:xxx2::.
3. Disable the IPv6 firewall, since it's dropping ~everything and can't be configured besides on/off.

OPNSense side

Open the admin interface
Firewall -> Settings -> Advanced -> Allow IPv6
Interfaces -> Overview -> WAN should contain an IPv6 starting with fe80:: note it down. It's the Local link address of the WAN interface.
System -> Gateway -> Add:
1. Name: FreeboxIPv6Gateway
2. IP Address: IPv6 address of the Freebox in the first delegate prefix, 2a01:xxx:xxx:xxx1::1 in our case
3. Upstream gateway: tick the box
4. Monitor IP: tick the box, if only to be warned/have logs if when things go South

Back to the Freebox side

Open http://mafreebox.freebox.fr/ in your browser
Paramètres de la Freebox -> Connexion Internet: Configuration IPv6 -> Délégation de prefixe: add the Local link address of the WAN interface into the Next Hop field for the first and second prefixes.

Back to the OPNSense side

Interfaces -> WAN:
1. Generic configuration -> IPv6 Configuration Type, set it to Static IPv6
2. Static IPv6 configuration -> IPv6 address, set it to any IPv6 address present in the first delegated prefix but the one ending in :1 since it's already used by the Freebox. I put 2a01:xxx:xxx:xxx1::2.
3. IPv6 Upstream Gateway: put the gateway we created, FreeboxIPv6Gateway.
Interfaces -> LAN:
1. Generic configuration -> IPv6 Configuration Type, set it to Static IPv6
2. Static IPv6 configuration -> IPv6 address, set it to any IPv6 address present in the second delegated prefix but the one ending in :1 since it's already used by the Freebox. I put 2a01:xxx:xxx:xxx2::2.

And now comes the salt: in IPv4, one would normally use DHCP to assign IP addresses. In IPv6, one can use DHCPv6 or SLAAC+RDNSS!

Anyway, I'm going with SLAAC only and hoping for the best.

Services -> Router advertisements -> WAN
1. Router Advertisements -> Router Only, since I use a fixed IPv6 for the WAN interface of the router, and don't provide network access to anything else on this segment.
2. Advertise Default Gateway, tick the box.
Services -> Router advertisements -> LAN
1. Router Advertisements -> Stateless, and pray
2. Advertise Default Gateway, tick the box.
3. Adversitse Routes, put the second prefix.

Another (mild) wave of saltiness: you need to punch holes into your firewall to allow incoming traffic for ICMPv6, otherwise things might just break. Fear not, there is a whole RFC about what should normally not be dropped, what will be dropped anyway, what a policy should be defined for, and what should be dropped unless a good case can be made, both for Transit Traffic and Local Configuration Traffic. At this point I just wanted things to work, so I courageously just gave up and trusted OPNSense "Automatically generated rules" to take care of this for me.

Oh, and if you have things like Jellyfin, set the firewall to "conservative", otherwise it'll randomly drop your websocket connections, and you'll waste a whole afternoon debugging it.

mat2 0.14.0

jvoisin — Thu, 23 Oct 2025 15:30:00 +0200

There is a new version of mat2: 0.14.0, with a new feature and a deprecation, to balance things out:

Add webp support
Improve reliability
Correctly handle PDF with weird filenames
Improve epub support
Improve MSOffice documents support
Add Python 3.13 and 3.14 support
Remove bubblewrap sandboxing

Bubblewrap sandboxing was removed as it was a significant source of issues over the years, was annoying to test in the continuous integration suite, didn't provide significant security improvement besides mitigating possible command injections in exiftool, and was best-effort anyway in the threat model.

Another important change is that the main repository for mat2 moved from 0xacab to github, for multiple reasons. First, because the web is a terrible place, 0xacab has to deal with abuses in various shapes and forms, and the easiest way to mitigate it is to make it non-trivial to register an account on the platform. Unfortunately, this makes it harder for people to report issues, or to contribute to mat2. Second, running computers is expensive, and I'd rather burn Microsoft's money than riseup's one. Third, Gitlab is becoming bloated and confusing, especially for such a small project as mat2. I'm not particularly happy about the move, as I'd rather use/depend on non-profit owned/operated infrastructure than an evil megacorp one, but it was a pragmatic decision. Worse case, I moved it once, I can always move it somewhere else in the future if needed.

As usual, if you know some python help is welcome.

Fixing "'humanize' is not a registered tag library" on postorious

jvoisin — Thu, 23 Oct 2025 14:00:00 +0200

At Nos oignons, we're running Tor exit nodes, but also a handful of services, like our website, some git repositories, some lightweight monitoring, … but also internal and external mailing lists. For the latter, we're using mailman3/hyperkitty with schleuder on top of it, making it an unholy pile of python, ruby, gpg and email shenanigans that the sysadmin team has to prevent from falling over.

Unfortunately, teaching sand to think was a mistake, and anything running on a computer will invariably fail at some point, mailing lists are no exceptions. Today I got the following email on the schleuder-admins@ list:

Net::ReadTimeout with #<TCPSocket:(closed)>
/usr/lib/ruby/3.3.0/net/protocol.rb:229:in `rbuf_fill'
/usr/lib/ruby/3.3.0/net/protocol.rb:199:in `readuntil'
/usr/lib/ruby/3.3.0/net/protocol.rb:209:in `readline'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:1017:in `recv_response'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:979:in `block in data'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:1027:in `critical'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:965:in `data'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:799:in `block in send_message'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:926:in `rcptto_list'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:799:in `send_message'
/usr/lib/ruby/vendor_ruby/mail/network/delivery_methods/smtp_connection.rb:53:in `deliver!'
/usr/lib/ruby/vendor_ruby/mail/network/delivery_methods/smtp.rb:101:in `block in deliver!'
/usr/lib/ruby/gems/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:643:in `start'
/usr/lib/ruby/vendor_ruby/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
/usr/lib/ruby/vendor_ruby/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
/usr/lib/ruby/vendor_ruby/mail/message.rb:2145:in `do_delivery'
/usr/lib/ruby/vendor_ruby/mail/message.rb:255:in `deliver'
/usr/lib/ruby/vendor_ruby/schleuder/mail/gpg/delivery_handler.rb:27:in `deliver_mail'
/usr/lib/ruby/vendor_ruby/mail/message.rb:253:in `deliver'
/usr/lib/ruby/vendor_ruby/schleuder/logger_notifications.rb:48:in `block in notify_admin'
/usr/lib/ruby/vendor_ruby/schleuder/logger_notifications.rb:29:in `each'
/usr/lib/ruby/vendor_ruby/schleuder/logger_notifications.rb:29:in `notify_admin'
/usr/lib/ruby/vendor_ruby/schleuder/logger_notifications.rb:13:in `error'
/usr/lib/ruby/vendor_ruby/schleuder/list.rb:379:in `rescue in block in send_to_subscriptions'
/usr/lib/ruby/vendor_ruby/schleuder/list.rb:362:in `block in send_to_subscriptions'
/usr/share/rubygems-integration/all/gems/activerecord-7.2.2.1/lib/active_record/relation/delegation.rb:98:in `each'
/usr/share/rubygems-integration/all/gems/activerecord-7.2.2.1/lib/active_record/relation/delegation.rb:98:in `each'
/usr/lib/ruby/vendor_ruby/schleuder/list.rb:361:in `send_to_subscriptions'
/usr/lib/ruby/vendor_ruby/schleuder/runner.rb:90:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/cli.rb:38:in `work'
/usr/share/rubygems-integration/all/gems/thor-1.3.2/lib/thor/command.rb:28:in `run'
/usr/share/rubygems-integration/all/gems/thor-1.3.2/lib/thor/invocation.rb:127:in `invoke_command'
/usr/share/rubygems-integration/all/gems/thor-1.3.2/lib/thor.rb:538:in `dispatch'
/usr/share/rubygems-integration/all/gems/thor-1.3.2/lib/thor/base.rb:584:in `start'
/usr/bin/schleuder:13:in `<main>'


[Django] ERROR (EXTERNAL IP): Internal Server Error:.eml
Subject: [Django] ERROR (EXTERNAL IP): Internal Server Error: /postorius/lists/<REDACTED>@nos-oignons.net/held_messages
From: <REDACTED>@lists.nos-oignons.net
Date: Thu, 23 Oct 2025 05:06:17 -0000
To: root@localhost, <REDACTED>@nos-oignons.net

Internal Server Error: /postorius/lists/<REDACTED>@nos-oignons.net/held_messages

TemplateSyntaxError at /postorius/lists/<REDACTED>@nos-oignons.net/held_messages
'humanize' is not a registered tag library. Must be one of:
account
admin_list
admin_modify
admin_urls
allauth
bootstrap_tags
cache
compress
d_gravatar
date_helpers
debugger_tags
decorate
gravatar
highlight
highlighting
hk_generic
hk_haystack
i18n
indent_text
l10n
log
markdown
membership_helpers
more_like_this
nav_helpers
p_gravatar
pagination
postorius_helpers
rest_framework
socialaccount
static
syntax_color
tz
widont

Request Method: GET
Request URL: https://lists.nos-oignons.net/postorius/lists/<REDACTED>@nos-oignons.net/held_messages
Django Version: 4.2.23
Python Executable: /usr/bin/uwsgi-core
Python Version: 3.13.5
Python Path: ['.', '', '/usr/lib/python313.zip', '/usr/lib/python3.13', '/usr/lib/python3.13/lib-dynload', '/usr/local/lib/python3.13/dist-packages', '/usr/lib/python3/dist-packages']
Server time: Thu, 23 Oct 2025 05:06:17 +0000
Installed Applications:
('hyperkitty',
 'postorius',
 'django_mailman3',
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'rest_framework',
 'django_gravatar',
 'compressor',
 'haystack',
 'django_extensions',
 'django_q',
 'allauth',
 'allauth.account',
 'allauth.socialaccount')
Installed Middleware:
('allauth.account.middleware.AccountMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'django.middleware.security.SecurityMiddleware',
 'django_mailman3.middleware.TimezoneMiddleware',
 'postorius.middleware.PostoriusMiddleware')


Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 1026, in find_library
    return parser.libraries[name]
           ^^^^^^^^^^^^^^^^^^^^^^

During handling of the above exception ('humanize'), another exception occurred:
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
               ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/contrib/auth/decorators.py", line 23, in _wrapper_view
    return view_func(request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/postorius/auth/decorators.py", line 66, in wrapper
    return fn(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 889, in list_moderation
    return render(request, 'postorius/lists/held_messages.html', context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/shortcuts.py", line 24, in render
    content = loader.render_to_string(template_name, context, request, using=using)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/loader.py", line 61, in render_to_string
    template = get_template(template_name, using=using)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/loader.py", line 15, in get_template
    return engine.get_template(template_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 33, in get_template
    return Template(self.engine.get_template(template_name), self)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/engine.py", line 175, in get_template
    template, origin = self.find_template(template_name)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/engine.py", line 157, in find_template
    template = loader.get_template(name, skip=skip)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/loaders/cached.py", line 57, in get_template
    template = super().get_template(template_name, skip)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/loaders/base.py", line 28, in get_template
    return Template(

  File "/usr/lib/python3/dist-packages/django/template/base.py", line 154, in __init__
    self.nodelist = self.compile_nodelist()
                    ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/base.py", line 200, in compile_nodelist
    return parser.parse()
           ^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/base.py", line 513, in parse
    raise self.error(token, e)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/base.py", line 511, in parse
    compiled_result = compile_func(self, token)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 293, in do_extends
    nodelist = parser.parse()
               ^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/base.py", line 513, in parse
    raise self.error(token, e)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/base.py", line 511, in parse
    compiled_result = compile_func(self, token)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 1088, in load
    lib = find_library(parser, name)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 1028, in find_library
    raise TemplateSyntaxError(
    ^

Exception Type: TemplateSyntaxError at /postorius/lists/ag@nos-oignons.net/held_messages
Exception Value: 'humanize' is not a registered tag library. Must be one of:
account
admin_list
admin_modify
admin_urls
allauth
bootstrap_tags
cache
compress
d_gravatar
date_helpers
debugger_tags
decorate
gravatar
highlight
highlighting
hk_generic
hk_haystack
i18n
indent_text
l10n
log
markdown
membership_helpers
more_like_this
nav_helpers
p_gravatar
pagination
postorius_helpers
rest_framework
socialaccount
static
syntax_color
tz
widont
Raised during: postorius.views.list.list_moderation

Since this is a django stacktrace complaining about a missing application, so it should simply be a matter of adding to /usr/share/mailman3-web/settings.py. Unfortunately:

root@bulbe:~# grep humanize /usr/share/mailman3-web/settings.py
    'django.contrib.humanize',
root@bulbe:~#

After a fair amount of cursing, spelunking in mailman-users and various strace+grep monstrosities, the solution was found: Instead of adding 'django.contrib.humanize' to the INSTALLED_APPS tuple in /usr/share/mailman3-web/settings.py as one would expect, it should be added in /etc/mailman3/mailman-web.py instead.

In the hope that this blogpost will help you waste less time on this than I did.

Silencing a Kitchencook teatime kettle

jvoisin — Mon, 13 Oct 2025 18:00:00 +0200

My household recently acquired a Kitchencook TEATIME kettle. It's quite fancy, with a handful of features that I don't really use nor care about, but I'm quite content with its 1.7L capacity.

Unfortunately, it beeps a lot. Here is a non-exhaustive list of things resulting in a dreadful unwanted noise: removing/putting the kettle from/on the base, when the water is at the right temperature, when one turns it off/on, when one presses a button, … sometimes even in the middle of the night for no apparent reason. This is fucking unacceptable behaviour, so here is how to fix it. Start by doing yourself a service and get yourself a screwdrivers kit from iFixit, as Kitchencook apparently hates their customers and decided to use Tri-angle screws for the base:

Once open, remove the 3 phillips screws fixing the PCB to the base:

The buzzer is the small cylindrical device on the bottom-left of the PCB:

It's a small piezo from ZFLY (Zhongshan Zhongli Electronics). The way piezoelectric speaker are working is by having a small piece of piezoelectric material fixed to a metallic diaphragm, and to excite it via a small alternative voltage, so that the disc will shrink/expand, causing the diaphragm to vibrate, and thus create sound. Silencing the infernal machine is simply a matter of removing the diaphragm altogether:

I'd recommend taping it to the plastic somewhere on the inside of the base, so that you can always put if back should you part with the device, and hand it over to some unhinged noise-lover maniac.

You should now be able to enjoy your tea in a blissful silence.

Snuffleupagus 0.12.0 - Stegodontidae

jvoisin — Tue, 19 Aug 2025 22:15:00 +0200

I just published a new release of Snuffleupagus, the hardening module for php7+ and php8+, version 0.12.0, codename "Stegodontidae", named after the extinct family of proboscideans, a cousin of the elephants we know (and love.) There aren't any new flashing features, only bug fixes and minor improvements, along with the usual support of newer PHP versions.

Changelog

Unify the default rules across all php versions
Snuffleupagus will no longer report outdated PHP versions
Fix a possible cookie-related crash
Fix a NULL-pointer dereference
Fix a minor portability issue
Improve modern Debian support
Improved documentation

As usual, if you want to help, we have some low hanging fruits ♥

See you in your PHP stack!

Manually fixing apt's "Unmet dependencies" error

jvoisin — Tue, 05 Aug 2025 22:00:00 +0200

I am, despite my best judgment and common sense, acting as a system administrator for a handful of projects/users, sometimes on my own, sometimes as part of a team. On the bright side, it's usually a great source of weird debugging/workaround stories, like this one.

With the new release of proxmox and with 30 minutes of free time, a sysadmin team I'm part of thought it would be nice to upgrade a box together. An admin ran pve8to9 --full, changed the repositories from bookworm to trixie, and ran apt dist-upgrade, and… their screen was filled with WARNING: ld.so: invalid GLIBC_TUNABLES `glibc.malloc.perturb=1,glibc.malloc.check=1,glibc.malloc.tcache_count=0': ignored.. Panic. So they hit <C-c> to investigate what was happening. Turns out, another admin threw those configuration options somewhere to "harden" the glibc allocator, and they're now deprecated, hence the message. No big deal, this can be fixed by removing those options, and running apt dist-upgrade again. Or can it?

# apt dist-upgrade 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libanyevent-perl : Depends: perlapi-5.40.0
                    Recommends: libasync-interrupt-perl but it is not installed
                    Recommends: libev-perl but it is not installed or
                                libevent-perl but it is not installed
                    Recommends: libguard-perl but it is not installed
 libcommon-sense-perl : Depends: perl (< 5.36.1~) but 5.40.1-6 is installed
 libnss-systemd : Depends: systemd (= 257.7-1) but 252.38-1~deb12u1 is installed
 libpam-systemd : Depends: systemd (= 257.7-1) but 252.38-1~deb12u1 is installed
 libsasl2-2 : Depends: libssl3t64 (>= 3.0.0) but it is not installed
              Recommends: libsasl2-modules (>= 2.1.28+dfsg1-9) but it is not installed
 libsasl2-modules-db : Depends: libdb5.3t64 but it is not installed
 libsystemd-shared : Depends: libssl3t64 (>= 3.4.0) but it is not installed
 openssl : Depends: libssl3t64 (>= 3.5.0) but it is not installed
 perl : Depends: perl-base (= 5.40.1-6) but 5.36.0-7+deb12u2 is installed
        Depends: libperl5.40 (= 5.40.1-6) but it is not installed
 perl-modules-5.40 : Depends: perl-base (>= 5.40.1-1) but 5.36.0-7+deb12u2 is installed
 systemd : Depends: libsystemd-shared (= 252.38-1~deb12u1) but 257.7-1 is installed
           Depends: libsystemd0 (= 252.38-1~deb12u1) but 257.7-1 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
[100]
#

Alright, let's try apt --fix-broken install:

# apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:

[…]

75 upgraded, 64 newly installed, 50 to remove and 530 not upgraded.
17 not fully installed or removed.
Need to get 0 B/118 MB of archives.
After this operation, 215 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
W: (pve-apt-hook) !! WARNING !!
W: (pve-apt-hook) You are attempting to remove the meta-package 'proxmox-ve'!
W: (pve-apt-hook) 
W: (pve-apt-hook) If you really want to permanently remove 'proxmox-ve' from your system, run the following command
W: (pve-apt-hook)   touch '/please-remove-proxmox-ve'
W: (pve-apt-hook) run apt purge proxmox-ve to remove the meta-package
W: (pve-apt-hook) and repeat your apt invocation.
W: (pve-apt-hook) 
W: (pve-apt-hook) If you are unsure why 'proxmox-ve' would be removed, please verify
W: (pve-apt-hook)   - your APT repository settings
W: (pve-apt-hook)   - that you are using 'apt full-upgrade' to upgrade your system
E: Sub-process /usr/share/proxmox-ve/pve-apt-hook returned an error code (1)
E: Failure running script /usr/share/proxmox-ve/pve-apt-hook
[100]
#

We're absolutely not going to do that, so let's use apt-mark to tell apt to leave proxmox-ve alone, and try the whole manoeuvre again:

# apt-mark hold proxmox-ve
proxmox-ve set on hold.
# apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... failed.
The following packages have unmet dependencies:
 libanyevent-perl : Depends: perlapi-5.40.0
                    Recommends: libasync-interrupt-perl but it is not installed
                    Recommends: libev-perl but it is not installed or
                                libevent-perl but it is not installed
                    Recommends: libguard-perl but it is not installed
 libcommon-sense-perl : Depends: perl (< 5.36.1~) but 5.40.1-6 is installed
 libnss-systemd : Depends: systemd (= 257.7-1) but 252.38-1~deb12u1 is installed
 libpam-systemd : Depends: systemd (= 257.7-1) but 252.38-1~deb12u1 is installed
 libsasl2-2 : Depends: libssl3t64 (>= 3.0.0) but it is not installed
              Recommends: libsasl2-modules (>= 2.1.28+dfsg1-9) but it is not installed
 libsasl2-modules-db : Depends: libdb5.3t64 but it is not installed
 libsystemd-shared : Depends: libssl3t64 (>= 3.4.0) but it is not installed
 openssl : Depends: libssl3t64 (>= 3.5.0) but it is not installed
 perl : Depends: perl-base (= 5.40.1-6) but 5.36.0-7+deb12u2 is installed
        Depends: libperl5.40 (= 5.40.1-6) but it is not installed
 perl-modules-5.40 : Depends: perl-base (>= 5.40.1-1) but 5.36.0-7+deb12u2 is installed
 systemd : Depends: libsystemd-shared (= 252.38-1~deb12u1) but 257.7-1 is installed
           Depends: libsystemd0 (= 252.38-1~deb12u1) but 257.7-1 is installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
[100]
#

You might think that using apt-mark hold for all the packages with unmet dependencies is the way to go, but you would be wrong, as it doesn't fix shit. You can check apt's documentation and ask the collective hivemind of the internet, but we didn't find anything to solve our problem. Then we realised that apt has a graph of all packages and their dependencies stored somewhere on the filesystem, and we found it via strace -f -e openat 2>&1 apt install --fix-missing | grep -oP "\"(.*)\"" | sort | uniq -c: it's /var/lib/dpkg/status. We can now edit it to remove the Depends: field of every package with broken dependencies to appease apt's dependencies solver via this big fat lie. Once done:

# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:

[…]

Setting up ca-certificates (20250419) ...
Updating certificates in /etc/ssl/certs...
openssl: /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.2.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.3.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.5.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.2.0' not found (required by openssl)
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned error exit status 1
Setting up busybox (1:1.37.0-6+b3) ...
Setting up libklibc:amd64 (2.0.14-1) ...
Setting up novnc-pve (1.6.0-3) ...
Setting up libz3-4:amd64 (4.13.3-1) ...
Setting up xz-utils (5.8.1-1) ...
Setting up libfribidi0:amd64 (1.0.16-1) ...
Setting up libopus0:amd64 (1.5.2-2) ...
Setting up libquadmath0:amd64 (14.2.0-19) ...
dpkg: dependency problems prevent configuration of python3-requests:
 python3-requests depends on python3-certifi; however:
  Package python3-certifi is not configured yet.
 python3-requests depends on ca-certificates; however:
  Package ca-certificates is not configured yet.

dpkg: error processing package python3-requests (--configure):
 dependency problems - leaving unconfigured
Setting up libproc2-0:amd64 (2:4.0.4-9) ...
Setting up proxmox-backup-restore-image (1.0.0) ...
Setting up ssl-cert (1.1.3) ...
openssl: /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.2.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.3.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.5.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.2.0' not found (required by openssl)
Signature algorithm of /etc/ssl/certs/ssl-cert-snakeoil.pem is not sha256. Recreating.
Could not create certificate. Openssl output was:
openssl: /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.2.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.3.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.5.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.4.0' not found (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.2.0' not found (required by openssl)
dpkg: error processing package ssl-cert (--configure):
 installed ssl-cert package post-installation script subprocess returned error exit status 1
Setting up libxcb-sync1:amd64 (1.17.0-2+b1) ...
Setting up dtach (0.9-7) ...
Setting up lsb-release (12.1-1) ...
Setting up dbus-system-bus-common (1.16.2-2) ...
systemd-sysusers: error while loading shared libraries: libsystemd-shared-252.so: cannot open shared object file: No such file or directory
dpkg: error processing package dbus-system-bus-common (--configure):
 installed dbus-system-bus-common package post-installation script subprocess returned error exit status 127
Setting up libconfuse2:amd64 (3.3-4) ...
Setting up libisl23:amd64 (0.27-1) ...
Setting up libcpg4:amd64 (3.1.9-pve2) ...
Setting up libcmap4:amd64 (3.1.9-pve2) ...
Setting up libpulse0:amd64 (17.0+dfsg1-2+b1) ...
dpkg: dependency problems prevent configuration of python3-pip-whl:
 python3-pip-whl depends on ca-certificates; however:
  Package ca-certificates is not configured yet.

dpkg: error processing package python3-pip-whl (--configure):
 dependency problems - leaving unconfigured
Setting up libquorum5:amd64 (3.1.9-pve2) ...
Setting up iptables (1.8.11-2) ...
Setting up fontconfig-config (2.15.0-2.3) ...
Setting up uidmap (1:4.17.4-2) ...
dpkg: dependency problems prevent configuration of cron:
 cron depends on cron-daemon-common; however:
  Package cron-daemon-common is not configured yet.

dpkg: error processing package cron (--configure):
 dependency problems - leaving unconfigured
Setting up python3-typeguard (4.4.2-1) ...
Setting up rsyslog (8.2504.0-1) ...

[…]


dpkg: error processing package pve-manager (--configure):
 dependency problems - leaving triggers unprocessed
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for sgml-base (1.31+nmu1) ...
Errors were encountered while processing:
 ca-certificates
 python3-certifi
 ssl-cert
 python3-requests
 dbus-system-bus-common
 cron-daemon-common
 liblwp-protocol-https-perl
 libwww-perl
 python3-pip-whl
 cron
 libpve-common-perl
 libproxmox-acme-perl
 python3-pyvmomi
 libpve-apiclient-perl
 dbus
 libpve-guest-common-perl
 libpve-storage-perl
 libpve-access-control
 libpve-cluster-perl
 libpve-http-server-perl
 pve-ha-manager
 libpve-cluster-api-perl
 libpve-notify-perl
 pve-manager
E: Sub-process /usr/bin/dpkg returned an error code (1)
[100]
#

Things are still broken, but less so, at least apt is able to upgrade/install/manage/… packages. Now it's simply a matter of running dpkg --force-all --configure -a, apt-get install --fix-missing and apt install <PACKAGE> (with <PACKAGE> being things listed in the Errors were encountered while processing: errors from the other commands) until you get no more errors. At this point, you can reopen /var/lib/dpkg/status, uncomment the lines you commented if they're still present, and resume your apt dist-upgrade. Still, it's sad that in 2025 a package manager is a simple SIGINT away from being completely broken.