Within 15 days of making the account, to add. If you missed it or decided you'd rather not give them the password to your previous email account (the alt objective for the Gmail-specific thing) you don't get a second chance.
I get that it's free but I trust them much less because of the way they handle that.
Note: The HTTP/3 QUIC module is not enabled by default and is considered experimental
Do note that despite not being enabled by default, it is enabled in the official binary packages.
There's a funny amount of layers to this thing but as far as I'm concerned, if it's a feature you ship in the default binary packages on your site, that is definitively enough for a CVE even if it's disabled by default.
This is also going to affect Linux distros, many are moving to x86-64-v2 or even v3. That comes with the same requirements this Win11 build is going to enforce.
There's plenty of life left in some of the later hardware not on the official Win11 support list, but hardware old enough to be excluded by this build is really overdue for retirement and/or being considered retrocomputing.
Technically always has, ROCm comes with a "backported" amdgpu module and that's the one they supposedly test/officially validate with. It mostly exists for the ancient kernels shipped with old long-time support distros.
Of course, ROCM being ROCM, nobody is running an officially supported configuration anyway and the thing is never going to work to an suitably acceptable level. This won't change that, since it's still built on top of it.
Even worse than that, they need to be able to make an arbitrary container from an arbitrary attacker-provided Dockerfile, or make fairly arbitrary calls to the Docker daemon (in which case you've already lost).
They're rather uninteresting for anyone self-hosting containers as the runc vuln doesn't offer a way to escape from within an already running container, while the BuildKit vulns all have fairly odd preconditions or require passing untrusted input. Quite the annoyance if you're running some kind of public cloud or public CI/CD service, though.
DMA-BUF being marked as "unstable" for a decade was a fucking joke. It's a protocol that's required to get any kind of meaningful hardware accel going, which nearly every app does nowadays. Within Wayland circles, it's been understood it's not going to change for years, as doing so would break nearly every single existing app, yet all kinds of bikeshedding prevented it from being moved to stable.
Hopefully this marks a turning point for many other similarly important protocols stuck in unstable/staging hell too, like pointer constraints and text input. If devs can't rely on basic functionality to be present and it takes more than say three years to commit to it, it's time to admit that either the process or the protocol is broken.
38-41ish. It'd be awkward to de-age below the appropriate local age of alcohol/consent/whatever, but that aside you wanna do it as early as possible. It's 20 more years of having a functional body, no reason to delay when you might randomly get hit by the bus tomorrow.
There are community backports (like Sury's Debian builds) for PHP, including a branch of PHP 5.6 originally released in 2014. Most other notable languages and major packages have something likewise as well, right down to major packages like Drupal 6. It's not always easy, but it's doable and the work is usually either already done or can be paid for.
Weird things that are truly too difficult to support are also often excluded. Eg Spectre/Meltdown fixes were non-trivial and had to be backported to a fairly wide range of things but that only went so far back. Some old systems just never got those fixes and instead have to be ran with a workaround ("don't run untrusted code"). I don't know how things are with the new offering but large complicated packages with lots of moving parts like OpenStack used to be excluded from the full extended support cycle before as well.
Windows software running in Wine/Proton can bypass the Windows layer and call Linux stuff directly. This is fine; Wine isn't intended to be a security layer by itself. Some of the Proton bits that Valve made to build a bridge between Windows games & the Linux Steam client does this, as well as pretty much every other bit of Wine internals.
Easy Anti-Cheat detects that it's running in Wine and if the game dev enabled Wine support, it downloads a binary that knows how to do that. That version of EAC doesn't run at kernel level, but it does scan your Linux userspace for cheats, or whatever Epic feels like doing today. As with every userland anti-cheat, the company making it can update it more or less anytime you're playing the game and since it's running in the context of the game, it has access to everything the game does. Same thing for most anti-cheat software really.
Everything was forked and should eventually end up on F-Droid, but most things haven't had a release yet. My understanding is that they're hoping to do everything right immediately, including having proper new branding and all the shared functionality from Simple Thank You.
The F-Droid versions of SMT apps are perfectly safe and shouldn't be going anywhere. (But if you have Google Play versions, I wouldn't trust those anymore, those are owned by ZipoApps now.)
They let you "reclaim"/"melt" things you bought before. I think this is an attempt to make a few rich people that are $30k or so in "complete their collection", and then probably repeat that year after year every time they release an updated pack.
For the port thing, you can set the
net.ipv4.ip_unprivileged_port_startsysctl to a lower value like 80 (may need to go lower if you also do email). It also applies to IPv6.The default of 1024 is for security, but the actual security granted by it is not really that relevant nowadays. It stems from a time where ports < 1024 were used by machines to trust other machines using stuff like rsh & telnet, and before we considered man-in-the-middle attacks to be practical and relevant. Around the start of this millennium, we learned better. Nowadays we use SSH and everything is encrypted & authenticated.
The only particularly relevant risk is that if you lower it enough to also include SSH's default port 22, some rogue process at startup might make a fake SSH server. That would come along with the scary version of the "host key changed" banner so the risk is not that high. Not very relevant if you're following proper SSH security practices.