jeroenhd

Double checking if you're sure you want to run `video of grandma.jpg.app` makes sense, prompting for execution for third party code isn't that strange.

The way Apple implemented it, where you can just sign your malware so the signature part is kind of useless, makes it weird, though.

They have over a hundred kernel configurations (multiplied by aarch64 vs amd64), many of which going back years, to do testing on. That probably doesn't help. People comparing them to open source projects like Arch and nixOS which support maybe one or two versions per platform are making a false comparison.

So far they're two days later than IBM/Red Hat. Not great, for sure, but they seem to be that far behind compared to the competition just yet.

If they push a backport that kills a million set top boxes because of changes in the network stack, they're not much better off than if they work a couple more days on testing.

It's native in that it doesn't start a whole web browser with hooks to native code, like most cross-platform applications. That saves a lot of RAM and storage (unless you're willing to subject yourself to testing with each platform's web view, which brings its own problems to the table for minimal benefit).

Based on the description, it looks like the author is using Linux. Native doesn't really exist there. There are a couple of flavours, but none of them are any more native than the other, and none of them are much more native than just rendering the UI yourself.

Modern Windows and Android development also often use the very same technique. Old Win32 (and I presume macOS, though the rise of iPad apps on macOS make me start to wonder) still offer some native-ish controls but they're not usable outside of their own platforms.

With egui you don't need to actually run a full copy of every version of Windows and macOS to see if the program runs. If it compiles, it'll work.

They may be popular, but that doesn't mean they're not silly. Requiring magical signatures to get rid of the scary "this person is trying to hack you" popups is quite a silly thing for an operating system to do.

Good from an open source perspective, for sure (though they have stopped fighting the good fight as much for practicality), but for a lot of Linux users (namely: companies), that good fight is of no real consequence, unfortunately.

I don't think people question remote accessibility as much as they question why remote accessibility is a matter of guessing the standard password.

You can have remote access through secure means. You might even have a web page open to the public if you secure some kind of safe login mechanism.

If your story is true, then these stores and chains better take the financial impact they hit out of their CEO's paycut, because they absolutely chose to risk it all for some minor cost savings. Maybe try to sue the manufacturer (though I doubt the judge will side with you if you're hit with the same attack just a week or so after the hack appeared on the news, without having fixed the problem).

That didn't stop any of the previous financial bubbles, financial crises, and progress-induced suffering.

If you make it through the devastation, you'll be one of the richest and most important people in the world. If not, throw a random frontman in front of the wolves and disappear into the background.

People panicked about the issue can either apply a quick IPTables mitigation or install the kernel Ubuntu hasn't released to production yet. It's annoying that Canonical is late, but it's not the end of the world either.

Unlike Arch or even Debian, Canonical has dozens of kernels to test and verify. The downside of supporting your software for ten years across multiple chipsets and even offering in-between kernel updates is that you need to test and maintain a shitload of kernels. Testing all of those takes time.

I hope they do a write-up about what went wrong here but all the big companies were weeks late to the party. My guess is that some of the patches were causing issues when backported, or Red Hat would've released updates much sooner as well.

Pretty much every OS I can think of has had one of these vulnerabilities. Microsoft had a bad one not so long ago that affected IPv6 packets, not even at TCP level. Dedicated RTOS packages that run Mars rovers have had network-level code execution exploits.

Network routing is complex enough from a management point of view, doing it fast and safely is very hard. Formal verification sounds nice, but the network stack is more than a dumb pipe.

For bugs like this, I hope the addition of Rust to the kernel will lessen the UAF vectors, but I'm sure it'll be years before that happens. The binder folks did a safe rewrite and encountered downstream companies hooking kernel tracepoints for state determination, I can't even begin to guess what they'll do to the network stack and how that'll affect adoption.

Canonical still maintains it. If you're just hosting some HTML or even PHP, you have a comfortable amount of time before you need to upgrade, assuming you're a paying customer.

I would expect paying customer to demand a dicount or their money back, but freeloaders get freeloader service.

They have kernels out you can install if you really need them, they're just not merged into production repos yet.

Install Ubuntu and you get 10-15 years of support of your current software stack.

Install Debian and you get 3-5 years of support.

Ubuntu also invests a lot into their desktop experience while Debian is closer to stock Gnome. That's more of a preference thing, though.

Debian has also traditionally been a pain to use with proprietary software. Nvidia drivers, WiFi firmware, you name it. It got better in the past years but it's hard to shake the bad name.

Because websites with almost no visitors are hit the hardest. A hundreds bots per minute hitting your server (if you host any kind of source code) versus one real visitor every other day is a great scenario to protect against.

The Russian government being stupid and evil isn't really Cloudflare's problem to solve. Neither is the lack of abuse prevention from VPN providers necessitating the extra challenges for VPN IP blocks. And, now that botnets are the norm, residential IP addresses too.

Obviously, Cloudflare's tools aren't the solution. The web needs to be closed down behind paid or real-identity accounts for websites to ditch these protections. It's only going to get worse from here.

I don't think carriers can be trusted per se, but if a carrier wants to interrupt your call, they can just kill the connection.

I've sent weird SMS messages through my (rooted) phone before. Silent SMS messages (useful for police trying to activate your phone for triangulation) still returned delivery reports a year or two ago, allowing someone to find out if someone else's phone is on without the target ever noticing.

I think Android removed the ability to send more annoying messages through its normal APIs (like flash SMS messages) but if you have access to any modem (either a smartphone or a full ESP32 dev board costing <50 bucks on AliExpress for 4G LTE), you can bypass any such restriction.

Carrier firewalls will probably filter these messages out but I wouldn't rely on it.

Google has clearly flagged this as "not a security issue", repeatedly. It's a weird bug for sure, but what's the scenario here?

Correct me if I'm wrong, but the carrier configuration messages can normally only come from carriers. The demo APK sends a message to the phone itself, but sending SMS messages requires special confirmation.

Practically speaking, what's the risk?

Phones take APN configuration through special kinds of SMS messages. This isn't just about routers.

Xe Iaso's blog posts poking fun at C(++) titled '"No way to prevent this" say users of only language where this regularly happens' has been quite busy this month.

Getting rid of C isn't the holy grail it might appear to be (Ubuntu has been working hard at rewriting sudo and coreutils in Rust and they have had plenty of bugs in the process), but I do hope the C projects will preemptively start fuzzing/running fil-C/invent new safety mechanisms for old code.

The integer overflow issue is only part of the problem. There are a couple underlying issues that make this exploit feasible: certain regexes produce extremely long bytecode, the integer overflow issue, and finally, a double free.

Rust will not protect you against exploding regexes, it will not protect you against integer over/underflows (unless you specifically call safe wrapping methods), but it will protect you against double frees if you use it sensibly (nothing prevents you from breaking the borrow checker and messing up memory if you write an unsafe {} block).

I see, I must've misremembered. It doesn't work anymore is all I know now.

Should be fixed now :)

The magic string was in the news but I'm pretty sure it's a hoax. When I tested it, it created enough of a "the input doesn't want to be processed" vibe to make the LLMs throw up rejections. I doubt Anthropic ever encoded it into their models.

I don't think that works anymore and I don't think the "special instruction" works either. Can't blame a guy for trying! I'm getting "helpful" spam from every place my email is posted (git is a common one) so I might as well try to get the bots out.

Don't think posting bioweapon recipes or bomb building instructions would go down with the moderation team, though.

Some of their examples are absolutely ridiculous, for sure. The lack of a fold-back design, like the surface, with pencil support is also a surprise to me. I suppose they'd still rather sell you an iPad with an operating system they don't let you control rather than bringing their laptop segment up to par with the competition.

But having had to emulate pinch-zoom in an Android emulator has made me wish I had my touch screen laptop back. Emulated touch events also don't work like real touch events, so web dev can also be a bit annoying sometimes.

It's just small things. I don't have a touch screen laptop anymore, but being able to physically tap things or reaching over to touch things just felt natural.

I have a phone with a QWERTY keyboard that also acts as a trackpad, yet I rarely use mouse mode on it. Seeing kids interact with laptops for the first time and touching the screen expecting them to work like every other device they use is also probably a sign of the times.

I understand why not everyone likes them, though. Some people prefer to disable their trackpads too, or prefer ball mice, or prefer mouse gestures over keyboard gestures. To each their own. I welcome the diversity.

Initializing core 0 on a modern system requires a Pentium CPU preconfiguring Minix to bootstrap the CPU. Training RAM is a whole new challenge. The simplistic designs of the 20th century don't apply anymore. Having USB to control boot is a necessity now and with Thunderbolt offering DMA access, configuring trust at a low level has also become a requirement.

There are plenty of things I don't like about UEFI. Going for pseudo-Windows APIs, for instance, or using FAT as a filesystem while better open-source filesystems are available.

I do applaud the efforts of people like the Coreboot team, trying to take control back for their devices, but the cut-down minimal boot manager they provide has yet to convince me to even try switching, to be honest.

Why not? Religious freedoms are about deeply held beliefs. It's not like a judge will evaluate the bible or quran to check if something is or isn't a religious freedom based on what someone's deity of choice supposedly stated.

Browsers were the original TLS trust store vendors. Operating systems started shipping trust stores because their OS came with a browser, not because they were the natural root of trust. Browsers also have tools to update revocation near-live, while operating systems lag behind by hours, or days in this case.

For your tool, remember to nuke Windows' automated certificate authority updates (separate from normal Windows updates) and possibly the automated intermediary cache. Microsoft publishes a list of trusted CAs/intermediaries periodically and they get automatically applied to Windows so websites don't need to send the full cert chain during TLS negotiation, and it has a tendency to cache trusted intermediaries as well.

Mozilla's trust store is one of the first to get updated when a revocation happens, as well as Google's CRLsets. Downloading full CRLs repeatedly would be a waste of time and bandwidth, that's why there's a specific distribution method for CA updates. I would extend your tool with a daemon that checks for revocation automatically, so you don't accidentally eMudhra yourself while browsers and the OS get updates next time something like this happens.

Touch screens on laptops are a bit like 4k screens or >60Hz screens. You don't expect to get much out of them, but once you're used to them, going back is annoying.

Everything from my watch to my printer has a touch screen, it's kind of strange how long Apple has held out, especially with the ultra expensive market they target with their laptops.

Apple's official API had revoked the certificate within hours. Only the Unix compatibility layer they sort-of maintain has this problem. This is hardly the first or only outdated Unix compat tool they ship with their OS.

Not great for unaware developers, but most macOS users are fine. Those who are aware can follow the steps in https://support.apple.com/en-us/149555 until Apple bothers to roll out an update.

Rather than prompting the mechanical parrot, you can also refer to Apple's own website: https://support.apple.com/en-us/149555

I don't know why they haven't rolled out an update if they've already wrote a whole article about patching the problem yourself.