BoppreH

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 1-byte private keys.

> 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.

This seems serious enough that I've contacted a few less-technical loved ones about it. I'm warning them of possible scams in the next days, perhaps even hosted on otherwise official pages.

Man, I love the spirit of the blinkenlights warning, but the "cotten-pickenen hans" bit makes it hard to use the original for anything.

I think you can do it in 5 weightings, because a 0 eliminates both balls. Worst case:

  scale(1,2) = 0
  scale(3,4) = 0
  scale(5,6) = 0
  scale(7,8) = -1  # If it was zero, the counterfeit would be ball #9.
  scale(6,7) = 0   # Must compare to a known-good ball. Here #8 is counterfeit.

If you're on Python and your problem is too big for a single regex, but too small for a full-blown parser like in the article, I can recommend the built-in re.Scanner[0]. It's a regex-based tokenizer[1] (so no recursive parsing) in the `re` module, that for reasons is completely missing from any official documentation.

You give it a pattern for each token type, and a function to process each match, and you get back a list of processed tokens.

Importantly, it processes the list in one pass and ensures the matches are contiguous, where a naive `re.findall` with capture groups will ignore unmatched characters. You also get a reference to the running scanner, so you can record the location of the match for reporting errors.

    import re

    # Initialize the scanner.
    scanner = re.Scanner([
      (r"\d+",   lambda scanner, token: ('COUNT', int(token))),
      (r"\w+",   lambda scanner, token: ('ANIMAL', token.removesuffix('s'))),
      (r"[,. ]",     None), # None -> skip token.
    ])

    # Scan a sample string.
    results, remainder = scanner.scan("45 pigeons, 23 cows, 11 spiders.")

    # Ensure we parsed the whole thing.
    assert not remainder

    print(results)
    # [('COUNT', 45),
    #  ('ANIMAL', 'pigeon'),
    #  ('COUNT', 23),
    #  ('ANIMAL', 'cow'),
    #  ('COUNT', 11),
    #  ('ANIMAL', 'spider')]

[0]: https://stackoverflow.com/a/693818/252218

[1]: https://en.wikipedia.org/wiki/Lexical_analysis#Tokenization

Growing up, many apartment buildings had doormen sitting behind a desk in the lobby. Some of the functions they provided:

- Identifying suspicious people and situations.

- Helping people carry things through the lobby.

- Passing messages before cellphones.

- Receiving packages.

- Making sure people in the lobby behaved.

And probably more that I never realized as a child. Doorman doesn't necessarily mean "suited guy standing attention outside the building next to a door". The locks were also electronic, so they didn't even have to stand up to answer intercom buzzes.

No, never. BST is defined as UTC + 1 hour. The leap seconds were making both UTC and BST jump around, and now neither will jump around anymore.

The time zones are defined as UTC + some offset, so no. What UTC will diverge from is solar time (UT1 in the article), so that solar noon might not happen at 12:00 anymore.

But because the sun's trajectory changes throughout the year, and we live in very coarse timezones already, it was always a bit useless tracking this with seconds precision.

Oops^2. I sent the email, thanks.

My first interpretation of the title was that UTC was in danger of something that needed fixing. It didn't occur to me that "continuity" meant in the mathematical sense. But thanks for bringing this to our general attention! It's great news.

On a side note, I really like how the site formatted the reasoning. I'll be copying it to my technical writing.

I'm well aware that HN doesn't have @ tags, but I would be surprised if dan doesn't have something listening for this specific string. And not a big enough deal to warrant an email in my opinion, but you're free to send one.

Good, point, I've reworded that bit.

Context: BIPM is responsible for the UTC time standard, and in this document they decide to stop adding (or removing) leap seconds, starting on 20th of May 2027 and lasting for the foreseeable future (until one leap hour is needed, but even then it's unclear if they'll do something). Together with the decision to not add a leap second in December, the 27 leap seconds that have been added so far should be the only ones, ever.

The page lists several good reasons for this, including:

- It's a common source of bugs.

- Solar time is not that important in a world of coarse timezones.

- IoT and anything that cannot receive time updates have trouble with leap seconds.

- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.

I'd also add:

- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to keep code that assumes "86400 seconds in a day" from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.

- Leap second unpredictability can make it impossible to calculate how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.

- The proper ISO8601 formatting of leap seconds ("23:59:60") is widely unsupported, breaking parsers, along with the assumption of how many seconds are in a minute, hour, or day.

---

EDIT: I've emailed [email protected] to change the title. It's avoiding editorialization, but I think it's also preventing the post from getting the attention it deserves.

I'm booking a yearly one-second-long holiday on my calendar, to celebrate all the headaches this will save me. Happy end of leap seconds!

Ops, bad comprehension skills on my part. I've amended the post to make the difference clearer.

On the other end I can recommend FritzBox. Rock solid and has a lot more bells and whistles than I expected, like wireguard support, NAS-like access by attaching USB storage, and more graphs than I know what to do with. It's the happiest I've been with an electronic purchase in a long time.

Also consider the case where you use Google password manager and your Google account gets locked for any (or no) reason. It's unclear whether you can even still use your passkeys, much less migrate them away.