BoppreH

I'd argue that's the fault of having default nullability, not the exceptions. You would have the same problem if every attribute access returned a Result<T> too.

And I'm not a fan of breaking control flow, but I still find it preferable to nulls. A null may travel far from the place where it was generated before blowing up, making troubleshooting harder, or it might come from a function you called for its side effect but forgot to check the return value. I gotta say I'm also a careful enthusiast of checked exceptions, it's great knowing which ways a function can fail.

But I think the consensus is growing that Result<T> (plus warnings for unused return values) is simply the superior choice.

If you mean type aliases, that's a good idea within a single codebase, but the distinction between different types of strings doesn't survive serialization so it wouldn't have prevented this error. What they need is a way to signal errors out-of-band, like Result<T> or exceptions.

If I was really desperate and could only return a valid string, I would probably use a message and add a random component to avoid ever matching two errors. Like SQL, where null != null.

No, that's just more in-band signaling!

Some badly designed password hashing algorithms (cough bcrypt cough) have maximum password lengths, ignoring everything after X characters. So it could happen that I set my password to a 100-character string, it gets saved as "==DANGEROUS_CRYPT_ERROR_length==", and then anybody can log in to my account by entering an unrelated long string that returns the same "error".

If a function promises a string result, it should only provide a string if the function succeeded. The null was much better than magic strings.

Yes, absolutely. Take for example this cURL command:

  NO_PROXY=1 curl -qs --data @./my\ message.txt -- \
  "https://user:password@example.com/user/${userid}/my%20message.txt"

Random parts of it will be interpreted by the shell, others by cURL, or the filesystem, or the remote server. They each have their own encoding rules, nested. I count ten distinct separators and nine ways of escaping/tagging. It's one command. No, just no.

We have seriously overused strings and we're now paying the price.

In-band signaling[1] strikes again. * should not have been used as special value, neither for "no password" in /etc/passwd nor "error while hashing the password" in crypt. I'm afraid we'll find many more of these abuses, specially in string manipulations. The null was ok, an exception (or equivalent) better, and Result<T> (or equivalent) best.

[1] https://en.wikipedia.org/wiki/In-band_signaling#Computer_dat...

From what I understand, biologists have the same problem when estimating the number of undiscovered species. One technique is to look at very popular, well studied biomes, and extrapolate the results to less studied biomes. Or ask niche specialists to guess different groups of species and add up the results, which is usually better than trying to estimate the population as a whole.

The errors bars will be huge, but it's better than "zero or more".

It's a bittersweet result, like finding asbestos in your house. I'd rather know than not, but I would much prefer not having it in the first place.

I understand this work was based on a dated snapshot. Will there be any continuous effort, scanning new PRs as they land, to prevent new weaknesses from being added?

Yes, why not? Chronological is infinitely better than a blank homepage.

The difference is that I'm subscribed to a variety of channels on YouTube. Yes, I do want to see their videos on the front page. That's what the Subscriptions page is doing anyway.

Agree, but it should at least show recent uploads from my subscription. It's stupid that I can visit "www.youtube.com" and not see a single video.

A socket is just a raw byte stream. It's a solid base layer, but you'll have to implement your own communication protocol on top, and it'll require copying the data from one process to another. A "stream" is the wrong metaphor for local data sharing.

The data is already in memory and the source program knows its "shape"; there should be an easy mechanism to provide access to that by default, like /proc or gdb but for arbitrary data structures and with better UI.

And the YouTube home page is blank if you have Watch History off. The recommendation algorithm still runs on the side bar of any video you watch, but the home page refuses to even show your subscriptions.

Another thing that has bothered me for a long time: we have far too many data isolation mechanisms, each with their own idiosyncrasies and trying to cover up for each other's gaps. Very very roughly, from source code up:

- Variable naming conventions (_field in Python).

- Lexical scopes.

- Visibility annotations (public, private, protected).

- Coroutines, threads.

- Packages/modules.

- Sandboxes.

- Processes.

- OS capabilities (pledge/unveil, SELinux, etc).

- Local user accounts.

- File permissions.

- Containers/chroot.

- User mode vs kernel (Ring 0 vs ring 3).

- Virtual machines.

- Cryptographic measures (secureboot, attestation, memory encryption, etc).

On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory if you're feeling brave.

If a script wants to know what file is currently open on my editor or what email attachments I recently uploaded, the editor or email client has to explicitly implement this feature via one of those limited mechanisms. Almost nobody does this, so we're stuck with black box applications that are hostile to customization.

I actually like `light-dark`. It's a shortcut to something that can be done more comprehensively with other, longer forms, but tailored to the most common (by far!) use case. It's a wart in the spec (specific color schemes as keywords) so that we can remove the warts in our code (media query blocks in CSS).

It's not like CSS was pure and elegant to begin with, so why not add an oddity that is actually useful?

I haven't checked this month, but the few times I used Google Search this year I saw egregious errors in the AI summary ~50% of the time. Things like confidently citing a statistic whose number appeared in the top 10 results, but misrepresenting what it pertains to.

This was an old gripe unrelated to today's issue. But your clarification is exactly why it left a bad feeling back then, the message certainly implies that my system is not getting all the security updates it could get.

Oh, the 18 gigabytes is not RAM, it's the storage. Language Tools indexes into the n-grams, so it doesn't have to keep everything in memory.

That would still be an RCE in the default install under certain circumstances, and the security advisory has no legible description or mitigations for an issue that other vendors have patched two weeks ago.

I would be perfectly ok if they had either quietly patched it earlier (like Debian), or communicated their prioritization, or they inexplicably delayed it but provided a high quality advisory (like Red Hat).

I don't like complaining about my fellow security engineers, but this one was real bad and is still personally affecting me.

> this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers or degrade data on the system

Red Hat disagrees[0][1]. They might be parroting Anthropic, and Anthropic might be exagerating the impact (likely!), but that's the current consensus about the vulnerability. If Ubuntu disagrees, they should have said something and not pasted "Cvss 3 Severity Score 9.8 · Critical" at the top of the page.

> A motivated attacker could probably do this on your network

I find that's still catastrophic given how centralized cloud environments are.

[0] https://access.redhat.com/security/cve/cve-2026-98432

[1] https://access.redhat.com/security/vulnerabilities/RHSB-2026...

Platform support. Oracle Cloud for example only provides images[1] for Oracle Linux, RHEL, Ubuntu, and Windows Server. Anything else you have to bring your own.

[1] https://docs.oracle.com/en-us/iaas/Content/Compute/Reference...

Self-hosted LanguageTool server[0] with browser addon. 18 gigabytes of n-gram data plus machine learning models. You can catch tpyos on 64K of RAM, but not any deep grammar mistakes, un-idiomatic phrases, or mistakes in common proper names.

[0] https://dev.languagetool.org/http-server.html

Thanks, I removed that part from my comment. Still, that's two weeks late.

The more I look at this the angrier I get. This is a CVE that Anthropic claims can get a Remote Code Execution on vulnerable systems, which includes default Ubuntu installs running any sort of Go server like Caddy. Bad enough that I shut down my personal website and self-hosted tools (sorry for any typos, my grammar checker is also down).

And this is how Ubuntu describes the vulnerability to sysadmins:

  In the Linux kernel, the following vulnerability has been resolved:
  ipv4: free inet_opt and ireq_opt after an RCU grace period
  tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
  child socket (newinet->inet_opt) without copying it.
  Another cpu can concurrently process a retransmitted SYN for the same
  request socket, and send a SYNACK from tcp_check_req().
  tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
  under rcu_read_lock() only, and ip_build_and_send_pkt() and
  ip_options_build() then read opt->optlen twice.
  Note that the SYNACK timer itself is not an issue: it holds a
  reference on its request socket, and inet_csk_reqsk_queue_drop()
  calls timer_delete_sync() before the child can be freed.
  Since commit 079096f103fa (“tcp/dccp: install syn_recv requests
  into ehash table”), request sockets are processed without holding
  the listener lock, so nothing prevents the child socket from being
  freed while the SYNACK is still being built. TCP child sockets do
  not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt
  with a plain kfree(), leading to a use-after-free in
  ip_options_build().
  A similar issue exists with request socket migration
  (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE
  program). reqsk_timer_handler() clones the request socket with
  inet_reqsk_clone(), so that the old request socket and its clone
  share the same ireq_opt, then reqsk_migrate_reset() clears the
  pointer in the old one. Another cpu holding a reference on the old
  request socket can still be using these options (sending a SYNACK,
  or creating a child in tcp_v4_syn_recv_sock()) when the clone is
  freed, and tcp_v4_reqsk_destructor() also uses a plain kfree().
  Readers already use RCU, and other paths replacing inet_opt
  (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use
  kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and
  tcp_v4_reqsk_destructor() as well.
  IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()
  duplicates the options. tcp_v6_reqsk_destructor() has the same
  migration issue with ipv6_opt, which is only set by CALIPSO. This
  will be addressed in a separate patch.

How is this in any way, shape, or form acceptable two weeks after the CVE was published?

Worse yet, the Ubuntu security incident page[0] lists "Ubuntu Priority: High" (as opposed to Critical, which would trigger an out-of-schedule patch). There's a "Why this priority?" link that simply says:

> Why is this CVE high priority?

> See ubuntu cvss score

That's it, we don't even get a period on this TBD of a sentence. It's followed by a generic link that explains what "Ubuntu Priority" is, but that page contradicts their choice. Note that it doesn't offer any mitigations either, and even the (horrendously unclear) description is copied from the NIST page, so there's no actual message from Ubuntu.

I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`, this is now the kick I needed to move to a different distro.

[0] https://ubuntu.com/security/CVE-2026-98432#priority-reason

> Its infrastructure was not compromised and no data was breached.

The private key of your globally trusted CA is infrastructure data and it was breached.

> All physical and logical security controls remained intact.

No, because you promised the CA Program that those keys would be HSM generated, FIPS 140-2 level 3 compliant. Ain't no compliant HSM in the world that will generate "4" as a private key.

> There were no end entity certificates issued out of the affected CA's.

I charitably read this as "revoking these weak CA didn't affect customers". But now your whole root is being revoked next week (which you forgot to mention). All your TLS customers get screwed.

Overall, good choice to give up, but lying on your way out is not a good look for a company with the tagline "Trust Delivered".

How do they get around blocks? Residential proxies?

My favorite PowerShell feature was barely mentioned: structured output!

Life is too short for parsing ad-hoc data formats from the 80s, and the "everything is a string" approach from *nix is a major contributor for the unreliability of shell scripts.

I don't trust Claude as personal assistant yet because too many websites block it from reading their contents, leaving Claude to guess and rely on very indirect sources. Performing actions online is even worse, with CAPTCHAs and whatnot.

It has made enough mistakes in this area that I now have a standing instruction (the only one) to always loudly warn whenever the official source for something couldn't be fetched.

You can't see how using "cotton-picking hands" as a negative term can cause backlash? If the phrase was something like "don't break anything in this cotton-picking rack", I would understand, but "keep your cotton-picking hands away"?

I'm not a native speaker, so I might have genuinely missed something here. Still, if I had this warning printed on my cubicle I would be fearing for my job everyday.