It will backfire in the short term, but it’s better to take the hit now than to wait until she causes more trouble.

About 10 euro for 12GB

Yes, it is. I’ve been using the OSS image and it has been working quite well.

It’s quite limited. I would recommend Grist instead.

It’s just a KDE fundraiser.

@marcan@treehouse.systems (Hector Martin from Asahi Linux) said the following on Mastodon:

Ars headline: “Found in the wild: The world’s first unkillable UEFI bootkit for Linux”

Article then proceeds to describe a toy GRUB wrapper bootkit that has nothing to do with UEFI firmware (other than running on UEFI systems like any other UEFI bootloader), does not persist in UEFI firmware whatsoever (it just is installed in the ESP partition on disk), and can be killed by not just a drive swap, but any OS reinstall, and even simply a GRUB update/reinstall.

And which looks like a toy demo from every angle, that any experienced security researcher could have cooked up in a couple afternoons. Hardcoded kernel patch offsets for a single specific Ubuntu kernel build and all. No novel techniques in use. This could have even been a homework exercise as far as I’m concerned.

In fact, it has an obvious mistake, touched on by the original article: LD_PRELOAD is set to a string trailing with " /init", no doubt a copy+paste of the command line used to achieve the same execution during testing. The correct string would have omitted the " /init", and the mistake would have caused an error message like this to be printed for every executable launched until LD_PRELOAD is overridden:

ERROR: ld.so: object ‘/init’ from LD_PRELOAD cannot be preloaded (invalid ELF header): ignored.

Furthermore, this bootkit is incomplete, since it relies on chaining into components installed via another mechanism (e.g. /opt/injector.so in the initramfs). A true bootkit only relies on its own first stage to drop all subsequent stages. That’s the whole point of setting up a boot chain compromise like this. Otherwise you can defeat it by removing any of the stages, even if the bootkit stage is intact. As it stands, this bootkit isn’t really a bootkit, it’s just a module signing side-step that allows a traditional rootkit to be loaded on a system with Secure Boot enabled (and, since the Secure Boot is still working as intended, that results in a prompt on the first reboot asking the user to install the “bootkit”'s certificate into the UEFI trusted certificate store, since it is obviously not trusted by default). So it can’t even be installed without clear warning to the user that something is wrong.

Come on, @dangoodin. I expect better than this from Ars, and I expect a correction, because this is just inexcusable misinformation. The original article clearly mentions how to kill this “unkillable” bootkit, which tells me you didn’t even read the original article all the way.

A simple remedy tip to get rid of the bootkit is to move the legitimate /EFI/ubuntu/grubx64-real.efi file back to its original location, which is /EFI/ubuntu/grubx64.efi.

Update: article & headline have been updated.

It just filters for anything “Google CEO” anything “head explodes” anything¹. However, this alone won’t help since you will also need another rule that doesn’t let anything pass that contains just “Google CEO” with a lower priority.

¹ Except newlines

TLDR: The complaint mentioned fr.xhamster.com so only the fr subdomain was blocked while xhamster.com remains available.

It certainly seems so judging by the amount of US politics

Cuban missile crisis any%

deleted by creator

This article spreads strong claims about a possible election conspiracy, yet seems to have little interest in verifying any of it and just runs with what they agree with.

The first part “The Data” discusses several statistical oddities, it then ends with the following statement:

One data scientist crunched the numbers: “It’s north of a 35 billion to 1 probability that you could win seven out of seven outside of recount range with less than 50% of the vote.”

It doesn’t mention who that “data scientist” is.

The next part “Election Software Compromised” starts off with telling that activists broke into election polling booths and downloaded copies of the software used to count the votes, then states those were hired by the Trump’s lawyers. Then it suggests that the source code could be used to create malicious versions of the software. It fails to mention how these would be installed en masse and by whom and just decided the voting machine software is compromised now. They’re technically not saying the software on the voting machines was comprised, but they were heavily implying it, and most reader who don’t develop software themselves will probably read it as such.

Then we continue “The Hack” (we’re just throwing the could haves out of the window now?). It starts with this fantastic quote:

“I think he’s guilty as fuck,” said Spoonamore.

This part kind of sums up the entire article, all claims are based off the writings of Stephen Spoonamore (“hacking and counter-hacking expert, cyber-security adviser, and government contractor" who’s apparently so good at cybersecurity that nothing about him can be found except for election interference claims).

Starlink was used to connect the election services to the internet in certain counties. Spoonamore also claims that Musk supplied all seven of the swing states with free Starlink service to make their ePollbooks work faster.

So? We’ve had HTTPS since 2000, this alone doesn’t make it insecure, but it’s yet another part that prepares for the following finale:

However, this hack could be deployed using any network connection. With the ePollbooks connected to the internet, it would have been possible to hack into the system and, using voter profiles of each registered voter who had been checked into a polling station, determine which candidate was gaining in each state. In the final hours, it would have then been possible, using the secondary pollbook created by the $1 million sweepstake, to determine which Trump voters had not shown up and mark enough of them on the ePollbook as having voted. These become the bullet ballots. Only 400,000 of them were necessary to tip this election—at one point Musk tweeted that millions had signed up to his pledge.

Spoonamore explains that with the ePollbook data updated to reflect the desired result, votes would then need to be added to the tabulation machines to match the ePollbook. The machines could have been “digitally stuffed” either over a network connection (facilitated by the compromised software on these machines) or via physical access to the tabulation machine. A second possibility involves the same compromise as above plus “human ballot stuffing”. He notes this could be the reason bullet ballots fall heavily in just a few counties.

“It’s actually a pretty standard hack,” he said.

The article covers itself quite well with all the could’ve would’ve been possible’s, but it still presents this scenario as very likely despite the mountain of assumptions leading up to it.

The final disclaimer part, starts with this:

Is this just “BlueAnon”?

Is this just the Left’s version of right-wing conspiracy theories that have played an outsize role in destabilising our institutions? Perhaps. But…

Then it’s not very responsible to just spread it wildly in the first ¾ of the article, is it?

Are you sure it actually syncs using a blockchain?

EDIT: It seems to be a modified version of Chrome sync with E2EE.

Which distro are you using? 1.x GB seems quite low.

How did you figure out it had issues with broccoli?. Were you checking your vegetable gallery for CSAM?

I’ve probably used it more than a hundred times now, but I still get confused about the current step sometimes.

And then what?

I’m not so sure about that

Boost.io seems to be a design proposal for boost.org

At least our military has guns, they do need to shout pew pew themselves though.