Well that's a first for me: an NTP Pool server sent a wildly wrong time, and systemd-timesyncd jumped the system time on Trastevere first forward 0.82s and then *backwards* 0.76s.
Thankfully Sunlight failed safe, crashed (which fired alerts), and recovered once the clock caught up.
WTF?
This ty + uv integration for PEP 723 might definitively make Python my go-to language for scripts. No more bash at any size.
https://astral.sh/blog/uv-ty-integration#first-class-support-for-python-scripts
I made my test site serve a small git repo, so you can test your git client.
$ git clone https://g3.emsign.filippo.io
$ git clone https://aaa.emsign.filippo.io
The macOS built-in curl, git, pip, python3, perl, ruby, and openssl all read /etc/ssl/cert.pem, which still has the emSign root, but they don't check revocation like Apple's Secure Transport libraries.
This is, uh, a problem. git and pip especially.
I added a short-term workaround to https://emudhra.we-have-a-problem.com/#macos-curl.
🚨 Six WebPKI Intermediate CAs are compromised.
This is bigger than Heartbleed, but a client-side issue.
Anything that verifies certificates against public roots, like most TLS clients, is/was affected.
Details, live test, patched versions and workarounds at https://emudhra.we-have-a-problem.com
Act now.
THIS IS NOT A DRILL.
If you package/distribute/maintain root stores or chain verifiers, act immediately.
If you know how to remove trust in a root, consider doing it now.
Otherwise, prepare to update systems as patches/mitigations come.
Go users, update to Go 1.27.3 or Go 1.26.10.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/0XofdebrAAAJ
RE: https://hachyderm.io/@golang/117470816794707999
Update everything that verifies certificates against public roots.
Anthropic found the origin of the NIST elliptic curve seeds: they were generated with drand48()!
No one was seriously worried, but this should put some FUD to rest, completing the NIST ECC rehabilitation arc… just in time to be retired in favor of PQ.
Also, we raised $36 Ki for ISRG. Yay!
No more leap seconds, ever! There isn’t one in December and they will be abolished in May.
The last one will forever be the 2016(?!) one. Didn’t realize having experienced leap seconds in prod dates me.
I’m not going to miss time going backwards, I’ll be honest.
Cobblestone-128 chunked (aka streaming) encryption in TypeScript for Node.js 22+, Bun, Deno, and all recent browsers.
One-shot, transform stream, and random access decryption APIs.
Uses the Web Crypto API for AES-GCM, with fallback on the noble cryptography libraries.
https://github.com/FiloSottile/cobblestone.ts
Interoperable with https://cryptography.io/en/latest/cobblestone/ and soon with the Go standard library.
If you actually read the “Passkeys are a trap. Do not use them.” post going around, you’ll find a transparent attempt to clumsily string together a conspiracy.
The post is predicated on the idea that a feature of WebAuthn called “attestation”, which is only used in high-assurance and usually corporate scenarios, and usually with physical hardware security keys, will be leveraged to hurt people, somehow.
The post posits that a website like X will bait and switch users: first, you get a passkey. Then, later, scary “attested” passkeys! This simply isn’t possible to do because attestation isn’t supported on the web for mass market, consumer authentication.
Attestation for passkeys (software-based, syncable credentials) is antithetical to their mass market goals, and would freeze out independent, non-corporate-backed credential managers. It’s an explicit non-goal of the designers of passkeys, who work together in a forum anyone can join.
And trust me, websites and apps like banks repeatedly asked for attestation at the beginning of the industry’s passkey journey. The platforms, browsers, and credential management apps have held firm that the goal of passkeys is reducing phishing and **not** some kind of trusted computing scheme. (And I will note: over my dead body!)
Besides the theory of the case being fundamentally wrong, there are several things that make the post disqualifying in terms of arguing something useful or important in the realm of security, privacy, and user authentication:
1. Intentionally presenting things that are complicated as inherently suspicious. (Delivering security by design can be complicated, yes!)
2. Describing TOTP as a “great solution” for adding security to a password-based account. When the most common threat model on the web is phishing (a word the post never mentions!), TOTP hardly buys you _anything_. TOTP is phishable.
3. Seeming to be unbothered by how many logical leaps are being taken without actually understanding the topic being discussed.
There are bad things happening in tech and untrustworthy people and companies do exist, but they’re largely in the AI space, not the “let’s stop people we love from getting compromised through phishing” space.
Publishing “Cryptographic Right Answers” for developers is a tradition by now.
Colin Percival started in 2009, Thomas Ptacek followed up in 2015, and then Latacora carried on in 2018 and 2024.
I put together an updated list. I'm very pleased (and mildly surprised) that at this point we have good post-quantum answers for everything.
Now we "just" need to get everything rolled out, and make Merkle Tree Certificates happen.
Let's get to work. See you in 2029.
I'm very excited to announce that the PLC Organization now has a statute! And a bank account! And a standard.site publication! All the important stuff.
The PLC Org is an independent Swiss Association that's meant to operate the main PLC directory, which collects and distributes signed updates to AT Protocol accounts.
https://filippo.io/mldsa@v1.0.0 is now updated to the Go 1.27 implementation and API.
It's also now a transparent wrapper on Go 1.27+ using type aliases, so the same program can use it alongside crypto/mldsa without issues.
Essentially, it's a drop-in compatibility replacement for crypto/mldsa.
We got paged the other night, so now I know a lot more about ZFS internals than I ever thought I would.
https://groups.google.com/a/chromium.org/g/ct-policy/c/RcKh1_LxoB0/m/7qlqM04fBwAJ
Triaged a large batch of issues found by a zkao.io scan. Some good bugs, but no vulnerabilities. (LLMs are especially bad at telling those apart.)
One or two of the math/big ones would have been vulns, but we finished moving math/big out of crypto a couple years ago! 🏁
LLMs found zero (0) vulnerabilities above SEV:LOW in Go crypto so far 💁♂️ 💅
Oh damn I had not seen the details of the MicroTik RCE: the client can send a public RSA key with correct N and e = 1 and the server will use it.
Two primitives/protocol things that would have prevented it: if RSA was defined with a fixed e, and if SSH clients sent a key hash instead.
What's the point if GitHub has unsandboxed RCEs, Hugging Face has unsandboxed RCEs, Forgejo has unsandboxed RCEs...
Anyway, we gotta stop shelling out to git in security contexts.
