Nginx gets forked by core developer
chameleon @ chameleon @kbin.social Posts 1Comments 106Joined 2 yr. ago
chameleon @ chameleon @kbin.social
Posts
1
Comments
106
Joined
2 yr. ago
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.
Takuro's own JP Twitter bio (urokutaja) claims involvement with both Pocketpair's games and Coincheck.
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.
Quest 64 French Vanilla more or less is that mod. Not totally sure what I think of it though. It's a huge improvement over the game's mechanics, but this is also one of those games where all the weird balancing quirks are part of the game's charm.
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.)
Well, my recommendations for anything semi-automated would be Ansible and Fabric/Invoke. Fabric is also a Python tool (though it's only used on the controlling side, unlike Ansible), so if that's a no-go, I'm afraid I don't have much to offer.
Realistically, there is only a trivial pure security difference between logging in directly to root vs sudo set up to allow unrestricted NOPASS access to specific users: the attacker might not know the correct username when trying to brute force. That doesn't matter in the slightest unless you have password auth enabled with trivial passwords.
But there is a difference in the ability to audit what happened after the fact if you have any kind of service storing system logs remotely or in a tamper-proof way. If there's more than one admin user on a service, that is very very important. Knowing where the compromise happened is absolutely essential to make things safe.
If there's only ever going to be one administrative user (personal machine), logging in directly as root for manual administrative tasks is fine: you already know who the user is. If there's any chance there might be more administrative users later (small but growing business), you should consider doing it right from the start.
You're most likely booted, otherwise you might need a live USB. Hopefully, the system isn't in read-only mode. What I'd recommend doing is:
cp /etc/fstab /etc/fstab.backup
To make a copy once. Then, nano /etc/fstab to run nano, a basic CLI editor. You can use the arrow keys to navigate and type freely in it. The hints like ^O shown on the bottom mean ctrl+o.
You'd use the arrow keys to go down to the line that probably says /dev/md0 /mnt/raid morecrap, put a # in front of it, press ctrl+w then enter to save. If that worked, ctrl+x to exit and try a reboot again.
Obviously can't promise this is "the" error preventing the system from booting, but it's generally a good idea to disable broken stuff like this to get the system working again, then fix it from there. Hopefully, this does the trick. Your RAID setup will not be activated on reboot after you do this but it's not going to permanently delete data or anything.
The RAID1 seems to be failing according to that screenshot. That breaks the "Local File Systems" task and since quite a lot of things tend to depend on that, many things usually end up failing in an annoying cascade failure. It's also failing with a timeout instead of a strict error, which is odd.
Either way, I'd try commenting that line for /mnt/raid in /etc/fstab for now and seeing if that makes the system boot. It's possible that journalctl -u dev-md0.service or systemctl status dev-md0.service might tell you more, but it's 50/50 if it'll be anything useful.
No, it comes together with a CLA being required to contribute. In other words, Canonical (and only Canonical) is still allowed to sell exceptions to the AGPL.
Yes, the post says there is no copyright assignment. That's extremely carefully chosen wording to avoid mention of the CLA which was made required in the same commit as the license change. It's "just" a super extended license that lets them do whatever, not assignment.
You can hardcode a specific version of nixpkgs, instead of a branch. With the new Nix CLI & flakes enabled you can do something like this:
nix run "github:NixOS/nixpkgs/b4372c4924d9182034066c823df76d6eaf1f4ec4#cowsay" "moo mooooooo"
That's the commit I'm seeing for nixos-23.11 today, and it should still give you that exact version of cowsay years from now.
Of course, the better option is to make a dev shell with flakes. Flakes come with a lockfile builtin that accomplishes the same effect, and there's no problems having different projects on different lockfiles/versions. It's a bit more work to learn, the Zero to Nix tutorials are pretty decent at teaching and come with examples though (ultimately most things are 30 lines of boilerplate and a list of packages that you want).
And they're also deleting/deleted all classic Minecraft accounts from before that. They invented an incredibly weird and needlessly obtuse process to extend the migration deadline by 3 months (true final deadline is now mid December 2023), but that's seemingly it. Everyone not paying too much attention to their email just gets $30 worth of game deleted because of a completely arbitrary decision.
A biggie you miss is the toolchain: the compiler/binutils/linux-headers/libc/libstdc++ combination. The libc and usually libstdc++ are key components of any install. The other parts usually don't make it to non-dev-desktops, but the distro couldn't be made without them, so they're virtually always available as packages.
Only exception is if the entire distro is cross-compiled or it's made exclusively for containers, but those kinds of special distros break every rule imaginable anyway. Some might not even ship a bootloader or a Linux kernel by themselves.
Don't bother "securing" directories like that. The meaningful permission bit is the write permission on the directory holding the file. cat ~/.bashrc > ~/.bashrc.new; put-malware-in ~/.bashrc.new; rm -f ~/.bashrc; mv ~/.bashrc.new ~/.bashrc or the like will still work if you have write permissions to /home/username at all. Marking the file immutable with chattr +i as root might be slightly more effective, but realistically still not enough in a lot of cases as the parent directory can still be renamed. Not to mention you've only found some of the low-hanging fruit; your text editor most likely also has a few ways to accomplish arbitrary code execution in its config/scripting/plugin files but it absolutely doesn't stop there.
Don't bother buying old systems because they can have free firmware. Ever since Spectre, CPU vulnerabilities have made old machines completely unsuitable for high-security purposes time and time again. Not all mitigations are equally effective and with mitigations on, performance takes a massive hit on those 10 year old machines. If you can get a reasonably new system with free firmware, that's good, though.
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.