i was wondering how many it was so far and it feel sorry for all the front end guys have to deal with this shit.

6th npm vulnerability this year...

Yeah it's way too effort intensive for routinely slamming out code. The main purpose for me of studying stuff like that is to sharpen my understanding of programming, rather than to actually use it. Look at the CompCert project though (compcert.org).

Implemented in OCaml, interesting. 😁

Seems like it's mostly used academically though?

OCaml is great, and there's an "extreme" version of it called Rocq (formerly Coq, the French word for rooster), that lets you literally prove correctness of your code: https://softwarefoundations.cis.upenn.edu/

Haskell

I'm learning OCaml right now and it's been pretty dang awesome so far.

I'm doing Advent of Code 2025 and have made it to day 7 part 2. I've never done an AoC where my first attempt to run the code was correct on both the sample input and real input so many times in a row. I'm in love with this language.

Oh boy, I tend to hate videos, but this was amazing. GPG is big trouble. I've had issues with it before but now it's solidified. I'm not ready to use Sequoia and I'm not keen on Rust culture, but something has to be done. I confess to having thought about rewriting GPG in Haskell or Ada or even Rocq, but only at the level of daydreaming.

hi motorola, pls

security in iot world has always been a shitshow

I bet LLMs are a big part of it because the barrier to trying different attacks is much lower now, and a lot of people don't even realize it.

is it me or are these increasing in frequency?

part of my is glad that i don't software development anymore because of it. lol

wow ain't that sum sheet... it is like everything is built with a backdoor. lets just throw all our old shit away now and buy the latest and greatest.

Living without some kind of firewall is becoming more dangerous all the time. Older hardware becomes expensive as new hardware becomes scarce, but also more vulnerable. One day a Firewall might not be enough.

CVE-2026-14266 has been reserved for this according to ZDI.

And any smart features you could ever want (and nothing you don't) can be accomplished with an rpi running kdeconnect. I'll never understand why people are so comfortable with IoT unless through ignorance

There is no way I will ever buy any smart TV or monitor again. My next one it's going to be the dumbest one ever, or it won't be.

And not any software, straight up adware.

And not just any adware, adware that asks you to install McAfee

My understanding is that you'd end up with two divergent histories and you can't tell which one is the original. I don't know how it could be abused off top of my head, but generally speaking people tend to find ways to abuse these kinds of things.

Please explain what you mean and how this could be abused. What does "real" mean in this context? They both have the same code. It would probably help if you can provide a specific attack that could actually cause harm rather than just stating facts that have unclear risk.

but looking back you have no way to tell which branch is the real one

It doesn't mutate history. It just creates a new branch of history in their own fork. Just like any new commit would do.

Right, it's not a serious exploit which would allow changing code, but it does allow compromising integrity because changing the id mutates history.

I don't understand. Why does having two commit IDs with the exact same code cause problems.

A green “Verified” badge on GitHub is supposed to mean that a trusted author signed it

The author did sign it. It is the exact same code.

An attacker can reissue the same signed code under a fresh ID that’s still verified to slip past.

To split past what? At best it seems that they would be able to have a different ID for the exact same code, which seems harmless? Slightly confusing at worst.

Nix also doesn't use PGP signatures, it requires a separate hash of the resulting commit (the files with the .git directory stripped by default).

A green "Verified" badge on GitHub is supposed to mean that a trusted author signed it, and its ID is a one of a kind fingerprint for that exact code. Turns out that the second promise of a unique fingerprint does not hold. It matters because security teams and package systems behind tools like Go, Nix, and GitHub Actions trust that ID as a unique handle for code. An attacker can reissue the same signed code under a fresh ID that's still verified to slip past.