The way releases are done and security is handled, one can argue that it makes sense to stay one major version behind - as long as it is a version to which security patches are applied regularly.
I follow this rule, or the variant where you wait for the first point release of a new major version, wherever possible. My desktop ran Debian bullseye until maybe about a month ago, when I updated to bookworm on its 5th point release. My browser of choice on that machine is firefox-esr, which is still on the 115.x branch.
I'm updating to bookworm on my daily driver laptop today - testing the full system backup now.
I've had minimal issues recently with debian but decades of debacles (not just debian, everything from RSX-11 to windows server) have made me cautious. So exhausted with wasted time.
> It's going to take something significant to get me off Bookworm.
Do you have experience using "Debian LTS"? It might have gotten me to stick to Bullseye for a little while longer, but I don't know much about it, and EOL was coming along soon.
> The upshot of all this is that admins who enabled some form of two-factor authentication (2FA) in GitLab are safe and unaffected by the vulnerability. And of course you enabled 2FA, didn't you?
...which begs the question: What US federal agencies aren't deploying their GitLab instances behind CAC auth at a minimum?
Basically all of them? Even the DOD Iron bank / repo1 has non CAC modes behind an auth provider. They have forced 2FA on from what I can see now though
My god I read up a little on the vulnerability and it might have been written as a feature to recover your account with any email address?? The module was called RecoverableByAnyEmail or something.
The intention was "any email associated with the user". You submitted an email address, Gitlab looked up the account associated with it, then sent the reset email to the supplied address. The issue was they didn't consider what would happen if you submitted an array of emails.
