briansmith

Just got back from the butcher shop. The butcher said he’s not interested in doing business with me and I shouldn’t come back. What a great day!

One more thought about OpenSSL: For over 10 years, maintaining OpenSSL has been, AFAICT, a completely thankless task for the people who do it. It is admirable how much they improved things considering the environment they are working in. That environment naturally results in a process where only improvements that can be made are ones that are *fully* funded or near zero cost, because most non-financial incentives have been totally annihilated. COBOL is a tempting, though unfair, analog.

Imagine that X25519, ChaCha, and Poly1305 hadn’t been developed and standardized during the 2010s.

Would they get standardized if the effort started today? (Ignore politics and mailing list etiquette.)

Would the TLS adoption curve have had a different shape?

Usually when I join a project I put in some effort to automate the installation of the development tools being used, including authenticating whatever is downloaded before it is installed. This also establishes a baseline of what’s supported and takes a big step toward making things reproducible.

Many times people refuse to run the script because they don’t want it to “ruin” their machine, and instead install things manually, without any integrity checks, of course, as who has time for that?

The Apple container tool, on the main branch as of yesterday, will verify the SHA-256 of the kernel image it downloads, before using it. https://github.com/apple/container/issues/1687

There is a good reason to use AES-256 instead of AES-128, whenever practical: you will never have to have an option for configuring this.

I believe most AWS outside of TLS load balancing unconditionally uses AES-256.

Does any vendor charge extra for AES-256 over AES-128 for terminating TLS? It would be interesting to see how much (little), if any, measurable performance difference there is, for commercial CDNs/load balancers.

It’d be good to see the mobile phone battery hit measurements.

Interesting clip from my long-ago boss on how Linkerd went from the edge of bankruptcy to profitability with a simple change to their open-source vs. paid maintenance model. Basically, pay-for-stability replaced stability-for-free, not unlike RHEL vs Fedora.

(Sorry about the website it is hosted on): @isaacrlevin@www.tiktok.com

I see LLMs adding difficulty for people to communicate in a non-primary (L2) language. The LLM helps them fix and clarify grammar. On the other hand, the more refining done, the more the output looks like AI output. Sometimes it’s too tempting to write in the native language & have the LLM translate; results are even more AI-ish. Often they lack most intuition of natural writing in L2, so the output looks fine to them. Now I often am not confident whether a thing is AI-proofed vs AI-produced.

At Mozilla, I as given the task of building an app signing mechanism for packaged installable web apps on FirefoxOS (Android but HTML5 instead of Java). I literally had a week to design it. Then I would have to implement in the next few. So, even though I hated it, I just chose Java’s signed JAR mechanism. This way, our partners could reuse the same tools they used for Android, and I just needed to implement the signed JAR verifier, which was something I could do in the time provided.

Why does OpenSSL (and forks) use `int` when it could use `enum`? I think the main issue is with the ABI of `enum`. It could be inconsistent even between compilers that agree on the rest of the ABI; in fact, the representation of enums was sometimes a compiler flag. C23 provides a potential solution: the equivalent of Rust’s `#[repr(c_int)]`. Then the issue becomes more of a *source* backward compatibility issue with older versions of the library, and the desire to support ancient compilers.

Switched to no-show socks. One of the best decisions I’ve made this year.

It seems like everybody who logged into the USCIS website yesterday saw a bunch of notifications about their case being approved, cards being produced, cards being mailed, etc.

Unfortunately, it was a bug in the website.

I read that the trend is for men’s shorts to keep getting shorter. I decided I needed to raise my tan lines accordingly. Unfortunately, I fell asleep at the beach and now I have a sunburn. Been off the court for multiple days now.

Other than that setback, my tennis has been progressing rapidly. I have 4 rated matches in the next three weeks.

With X25519MLKEM, we are concerned that MLKEM might be broken *xor* that a quantum computer might break X25519. But, we’re not concerned about the case where MLKEM is broken *and* a quantum computer breaks X25519?

What’s the best write-up for how we got there? I’m looking for linkable source that argues in favor of X25519MLKEM over P384MLKEM and P521MLKEM, that wouldn’t also favor, say, P192MLKEM over X25519MLKEM.

A nice proposal for reducing the attack surface of the Lean VSCode extension, eliminating unmaintained dependencies and separating the parts that download/install executables from the core functionality: https://github.com/leanprover/vscode-lean4/issues/790