chameleon

chameleon , 25 days ago

This list genuinely looks like some of the marketing they had around Win7 times. No joke.

Snap? Yep, advertised feature. Touchscreen stuff? Absolutely! Better search? Yeah, advertised (and it was true in Windows 7!). New app to make movies? They got it. I guess the Win 7 page was missing Widgets. That was a Vista feature instead...

chameleon , 26 days ago

IRCv3 has extended IRC quite a bit over the past decade, fixing a lot of minor pain points if clients support the fixed versions of the protocol.

chameleon , 1 month ago

Given that the UUID changed, you almost certainly made a new LUKS container, overwriting the old one. That's bad, because the LUKS header is the only source of the actual encryption key that was used, and making a new one will overwrite both the main header as well as its backup copy immediately. Your password/keyfile/whatever is merely used to decrypt the part of the header that has the actual encryption key, and that's gone in that case.

Unless you have access to a header backup from before that, there's a fairly strong chance it's irrecoverable. I'd suggest going through any archives you might have to see if you have such a backup - most of the instructions on the Gentoo wiki encourage making one, so you might have made one through the power of copying & pasting instructions. Should be a file of around 16MB.

chameleon , 1 month ago

The KeePassXC people are also volunteers and dealing with the fallout of this decision.

chameleon , 1 month ago

Some people are opposed to sudo being a fairly complex program with an awkward to understand configuration language and a couple of methods that can fetch config from elsewhere. Fixing upstream sudo can't happen because those features exist and are presumably used by some subset of people, so straight up removing them is not good, but luckily doas and sudo-rs exist as alternatives with a somewhat stripped featureset and less footguns.

Others are opposed to the concept of SUID. Underneath all the SUID stuff lies far more complexity than is obvious at first sight. There's a pretty decent chunk of code in glibc's libdl that will treat all kinds of environment variables differently based on whether an executable is SUID, and when that goes wrong, it's reported as a glibc bug (last year's glibc CVE-2023-4911 was this). And that gets all the more weird when fancy Linux features like namespaces get involved.

Removing SUID requires an entirely different implementation and the service manager is the logical place for that. That's not just Lennart's idea; s6, as minimal and straight to the point as it tends to be, also implements s6-sudo{,d,c}. It's a bit more awkward to use but is a perfectly "Unix philosophy" style implementation of this very same idea.

chameleon , 1 month ago

SO already was. Not even harvested as much as handed to them. Periodic data dumps and a general forced commitment to open information were a big part of the reason they won out over other sites that used to compete with them. SO most likely wouldn't have existed if Experts Exchange didn't paywall their entire site.

As with everything else, AI companies believe their training data operates under fair use, so they will discard the CC-SA-4.0 license requirements regardless of whether this deal exists. (And if a court ever finds it's not fair use, they are so many layers of fucked that this situation won't even register.)

chameleon , 1 month ago

View -> User Interface, change to Tabbed or Tabbed Compact (or Notebookbar in old versions).

chameleon , 1 month ago

This is a fork of the evaluator/language implementation/daemon/builder/whatever you want to call it. The other one (Auxolotl) is a fork of Nixpkgs, the repository of build scripts and all the NixOS misc pieces.

Or put into other terms, this is a fork of APT/RPM as well as their associated builder tools, while Aux is a fork of Debian/Fedora/whatever. The Nix evaluator is a much more complex piece of software than most other package managers so it does benefit from having a dedicated team working on it.

chameleon , 1 month ago

Lemmy (and Kbin for that matter) very much do the same thing for posts. I don't think they fetch URL previews for links in comments, but that doesn't matter: posts and comments are both fairly likely to end up spreading to Mastodon/etc anyway, so even comments will trigger this cascade.

Direct example: If you go to mastodon.social, stick @[email protected] in the search box at the topleft and click for the profile, you can end up browsing a large Mastodon server's view of this community, and your very link has a preview. (Unfortunately, links to federated communities just result in a redirect, so you have to navigate through Mastodon's UI.)

chameleon , 1 month ago

If you're a gamedev trying to make a decent mobile game, you're competing on all the usual fronts like price and perceived quality, but competing for attention has gotten a whole lot harder when [arbitrary card game] has a hour of dailies, [arbitrary gacha game] always has a special campaign going and [arbitrary fake gambling game] is about to have its battle pass end and they're only halfway through. And that has gone up by so, so much over the past decade. It was never good but it's gotten absolutely egregious. At this point, even any generic snake clone will have a battle pass.

Every person that ends up committed to a couple of those long-term-commitment games ends up having much less time for other games. And they make a lot of money, which means they also end up having a hell of a marketing budget.

chameleon , 1 month ago

The point of this is to implement some form of privilege escalation without the SUID mechanism. sudo, pkexec and doas are all SUID.

chameleon , 1 month ago

Looking at the implementation, it doesn't really implement sudoers or tools like sudoedit in any way. systemd-run has already been an existing tool for quite some time and this is really just a different CLI for it. That tool asks systemd to make a temporary new service and immediately run it. That, in turn, requires blanket yes/no approval for org.freedesktop.systemd1.manage-units via polkit.

So with run0, you can either do everything or you can do nothing. In-betweens are just not a thing at the moment. There's very little new backend code running as root.

run0 bash should behave very similar to something like systemd-run --uid=0 --gid=0 --wait --same-dir --send-sighup --pty --pipe --collect bash and the majority of those options have been available for quite a while.

chameleon , 2 months ago

I think they'll give it a genuine shot. These stalking services pop up like weeds and every time it gets some media attention they end up with significant problems not much later. dis.cool was the last well-known entry but there's been more.

chameleon , 2 months ago

These things are always easy to say in hindsight, but I do believe that a closer review of the build system shenanigans used to install the backdoor would have at least raised some questions.

Nobody noticed it because nobody is reviewing autotools spaghetti and especially not autotools spaghetti that only exists as shipped in a tarball. Minor differences in those files are perfectly normal as the contents of them are copied in from the shared autoconf-archive project, but every distro ships a different version of that, so what any given thing looks like will depend on the maintainer's computer. And nearly nobody has a good understanding of what any given line in a .m4 file is going to ultimately lead to the execution of regardless, so why bother investigating any differences? The maintainer of Meson has a good take on this.

Shipping tarballs without any form of generated files and having a process to validate release tarballs against the repo would be a good step, but is much easier said than done for a variety of reasons. Same thing can be said for shipping without any form of binary files in the repo, there's quite high value in integration tests and xz's README for the test blobs has correctly included this paragraph for 16 years:

Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.

chameleon , 2 months ago

Test files often represent states that can't be represented in the library proper. Things like "a tree where node A is a child of B and node B is a child of A", "the previous instruction repeated x times" where x was never set or there was no previous instruction, or weird combinations of mutually exclusive effects. More often than not, you can't really generate those using the library itself, as libraries tend to be written to reject those kinds of invalid states (there's only so much you can do in C but in functional programming land, "make invalid states unrepresentable" is a straight up mantra).

Even if you did manage to do that, using the system under test to generate test data for the system under test is generally not very useful by itself; you'd need some kind of extra protections on top to make sure the actual test files continue to be identical between revisions (like hashing them). Otherwise, a major incompatibility could be easily overlooked. But that also makes it hard to make any kind of valid changes to the library at all. Worse yet, some libraries don't implement everything needed to generate the test files: even xz is missing pieces, for example there's an lzip decompressor but not a compressor.

There's some arguments to be made for separating the test system from the main distribution, but the end result will likely be that nobody runs the testsuite at all. It's difficult enough to get distros to do it in the first place.

chameleon , 2 months ago

They already did before this. MS-hosted Office 365 is running the vast majority of worldwide corporate email and hosts a significant amount of corporate files on business OneDrive/SharePoint. I'll never understand why companies bought into 'the cloud' so easily.

chameleon , 2 months ago

You're looking at the wrong line. NixOS pulled the compromised source tarball just like nearly every other distro, and the build ends up running the backdoor injection script.

It's just that much like Arch, Gentoo and a lot of other distros, it doesn't meet the gigantic list of preconditions for it to inject the sshd compromising backdoor. But if it went undetected for longer, it would have met the conditions for the "stage3"/"extension mechanism".

chameleon , 2 months ago

For any given tag, GitHub will always have an autogenerated "archive/" link, but the "release/" link is a set of maintainer-uploaded blobs. In this situation, those are the compromised ones. Any distro pulling from an "archive/" link would be unaffected, but I don't know of any doing that.

The problem with the "archive/" links is that GitHub reserves the right to change them. They're promising to give notice, but it's just not a good situation. The "release/" links are only going to change if the maintainer tries something funny, so the distro's usual mechanisms to check the hashes normally suffice.

NixOS 23.11 is indeed not affected.

chameleon , 2 months ago

Sam Jones's FAQ is by far the best single source, links to other solid sources for more in-depth technical details and also lightly debunks a few things.

The main thing sources online disagree on are which distros are affected. That's because it's not a simple yes/no and some distros are taking a nuanced approach in their public communication, while others have chosen the sledgehammer in an attempt to get people to upgrade their systems but keep/kept the nuance in the back room where the audience understood not everything was known yet. Some distros are underselling how vulnerable they were, others are overselling it.

chameleon , 2 months ago

Realistically, I think vendors will be trying to push their crap using this attack as leverage. They did it with Heartbleed, Shellshock and the Log4j issue. Their software won't/wouldn't accomplish anything, just like it didn't with those issues, but they're sure as hell gonna try to make it seem like it does.

chameleon , 2 months ago

Unfortunately, it's definitively an instance of intentional design. This whole consent dialog thing became a booming "consent management platform" industry. Many of them advertise better acceptance rates than the competition, or used to but have removed those claims in more recent times now that the big GDPR boom is over.

This particular dialog is TrustArc, who are infamous. At one point they defended it with a "well, we gotta retry if it fails to make sure your preference is expected, and we can't know if your adblocker is causing it to fail or if it's just a fluke", which is one of those things where they say something that's not totally wrong but you know they're lying through their teeth.

chameleon , 2 months ago

This is a fun one we're gonna be hearing about for a while...

It's fortunate it was discovered before any major releases of non-rolling-release distros were cut, but damn.

chameleon , 2 months ago

Won't help here; this backdoor is entirely reproducible. That's one of the scary parts.

chameleon , 2 months ago

Reproducible builds generally work from the published source tarballs, as those tend to be easier to mirror and archive than a Git repository is. The GPG-signed source tarball includes all of the code to build the exploit.

The Git repository does not include the code to build the backdoor (though it does include the actual backdoor itself, the binary "test file", it's simply disused).

Verifying that the tarball and Git repository match would be neat, but is not a focus of any existing reproducible build project that I know of. It probably should be, but quite a number of projects have legitimate differences in their tarballs, often pre-compiling things like autotools-based configure scripts and man pages so that you can have a relaxed ./configure && make && make install build without having to hunt down all of the necessary generators.

chameleon , 2 months ago

The base runtime pretty much every Flatpak uses includes xz/liblzma, but none of the affected versions are included. You can poke around in a base runtime shell with flatpak run --command=sh org.freedesktop.Platform//23.08 or similar, and check your installed runtimes with flatpak list --runtime.

23.08 is the current latest version used by most apps on Flathub and includes xz 5.4.6. 22.08 is an older version you might also still have installed and includes xz 5.2.12. They're both pre-backdoor.

It seems there's an issue open on the freedesktop-sdk repo to revert xz to an even earlier version predating the backdoorer's significant involvement in xz, which some other distros are also doing out of an abundance of caution.

So, as far as we know: nothing uses the backdoored version, even if it did use that version it wouldn't be compiled in (since org.freedesktop.Platform isn't built using Deb or RPM packaging and that's one of the conditions), even if it was compiled in it would to our current knowledge only affect sshd, the runtime doesn't include an sshd at all, and they're still being extra cautious anyway.

One caveat: There is an unstable version of the runtime that does have the backdoored version, but that's not used anywhere (I don't believe it's allowed on Flathub since it entirely defeats the point of it).

chameleon OP , 2 months ago

Login isn't necessary, but there is no :latest tag published so you need to pull a version that exists. The current version is at codeberg.org/forgejo/forgejo:1.21.8-0 or at :1.21 if you want one that tracks patch updates (as found in the container registry).

chameleon , 2 months ago

My casual-browsing-only netbook is currently running on a RAID0 setup between the internal eMMC and the microSD card because I think it's funnier that way. Nothing useful's stored on there and it's one nixos-rebuild away from being reinstalled so I don't mind the inevitable breakage.

chameleon , 3 months ago

Someone hacked in a clear (in-game). First time it happened to this level, but not the first time it happened overall.

chameleon , 3 months ago

sudo mv /etc/default/grub /root/old_etcdefaultgrub to get it out of the way, then sudo dnf reinstall /etc/default/grub to reinstall the package that provides it, giving you a fresh unmodified copy. Should work for practically any config file on Fedora.

chameleon , 3 months ago

Storj is blockchain stuff with the storage and bandwidth provided by individual node operators. They've kinda tried to bury the whole blockchain stuff and generally keep it removed from their main signup/pricing/usage flow; customers pay in USD and never have to see any of it. But it's still there in the background and it's still the main reward system for node operators.

There's some clickwrapped T&Cs for operators that set some minimum requirements, they've made sure one node leaving doesn't cause data loss, but I'd still be very wary of using them for anything irreplaceable. It only takes one crypto crash or the like for the whole thing to die out, and while they might end up suing some guys running an old NAS out of their garage, that's not gonna get your data back.

chameleon , 3 months ago

DP is very much not free. VESA themselves is happy to tell you that DisplayPort is excluded from their list of free standards, and the leaked copies of old standards are stamped with a "distribution to non-members is prohibited" notice on every page.

I'm not sure where that misconception came from, but it really needs to stop at some point. The best thing to say about VESA is they're slightly less bad than the HDMI Forum. But only by so little.

chameleon , 3 months ago

This is a shot in the dark, but since the permissions look fine to me, the only other thing that comes to mind is that the SELinux contexts might not have been copied. Fedora is one of the few distros that enables SELinux in enforcing mode right out of the box. That can be very complex to understand if it breaks.

There is a Fedora documentation page about SELinux. The /var/log/audit/audit.log log file should be full of errors relating to your /home if it broke. I believe that stat /home and stat /new_home should display the SELinux context if SELinux is active, and they should be identical.

Also possible I'm totally off the mark, though, it's just a possibility.

chameleon , 4 months ago

I don't think Factorio is suitable for a first-time gamer. The way the inventory, hotbar and the map work aren't immediately obvious if you've never played a game. If you do try, at least turn biters off. The time pressure that's added by having to set up defense would be difficult enough to handle, but offensive combat is quite the struggle if you're still trying to learn basic gaming controls. You'd be dealing with things like swapping hotbars to one with grenades & stuff, control schemes changing the moment you get into a vehicle and weird targeting quirks. And by the time you get to trains or advanced oil cracking quite a lot of people tend to drop off the game in general.

I'd start with something like Minecraft on peaceful difficulty, then give easy or normal a try after a couple of hours if that goes well. Peaceful leaves time to learn all the basic controls and is fun enough to run around in by itself, and you're not going to get blasted by a creeper that fell behind you.

chameleon , 4 months ago

For the port thing, you can set the net.ipv4.ip_unprivileged_port_start sysctl 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.

chameleon , 4 months 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.

chameleon , 4 months ago

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.

chameleon , 4 months ago

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.

chameleon , 5 months ago

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.

chameleon , 5 months ago

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.

chameleon , 5 months ago

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.

chameleon , 5 months ago

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.

chameleon , 5 months ago

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 host side, unlike Ansible), so if that's a no-go, I'm afraid I don't have much to offer.

chameleon , 6 months ago (edited 6 months ago)

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.

chameleon , 6 months ago

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.

chameleon , 6 months ago

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.

chameleon , 6 months ago

Not that high. Spotify uses some pretty tight compression (not good, just tight); most users get 96-128kbit/s AAC, premium can go a bit higher if opted in. That works out to about 16KB/s or 58MB/hour, assuming nothing's cached.

Bandwidth pricing very much goes down with scale, not up. But even the non-committed AWS pricing at Spotify's scale is 2 to 3 cents/GB. You end up paying way less than that with any kind of commitment and AWS isn't the cheapest around to begin with.

chameleon , 6 months ago

Aww, okay. I'll just have to go back to licking Switch cartridges then...