.plan-26-34: Am I human or am I antibotty

TESSERA v2 beta embeddings are in the TZE explorer, security embargoes being outrun by agents, opam packages now need humans behind them, prometheus and eio releases

I've been in Ireland again this week so not a lot of work time. I did finish the TESSERA v2 beta embeddings conversion and queued up a new geotessera release, handled some OCaml security releases and noted down my thoughts on security embargoes, and how opam-repository now requires a human behind every package. There are also fresh releases of prometheus 2.0 and eio 1.5, and some fun links to finish.

I also finished my POPL reserve PC reviews, with a fair degree of slop writing but also a really interesting one that I spent quite a while on and really enjoyed.

1 Geotessera 0.10 and the embeddings explorer

I prepared a v0.10.0 release of geotessera (#374) that I used to finish the Zarr conversions of the v1.0 and v2-2B-L~beta1 embeddings. The latter are interesting not only for their massive accuracy improvements (the distilled v2 embeddings lead every open and proprietary embedding product tested in the v2 paper), but also because of their use of Matryoshka embeddings in which the dimensions of each embedding are ordered by importance so that a prefix of the full vector is also a usable lower-dimensional embedding.

I added support in the latest TZE that I've pushed to https://tze.geotessera.org to inspect these in detail. You can now view the separate d4, d16 and d128 slices of the embeddings just by clicking on an area there, and also see it animate through time. A lot of quick analyses can happen just using the first 16 dimensions; our v2 paper finds that the d16 prefix keeps around 92% of the full 128-dimensional accuracy at just an eighth of the storage.

Next week, I'll get the released library out at last! I just need to refresh some of the Zarr example classifier code.

2 Security holes and secret agents everywhere

The Cohttp path traversal I wrote about last week is now fixed and released in cohttp 6.3.0, with the advisory published as OSEC-2026-16. This, and a few other bugs that came in this week, prompted me to write a longer note about where this is all going.

It weirded me out to see probes matching the exact bug pattern hit this website within minutes of my opening the public PR, and also to realise that my own agents could generate a working exploit from just a rough description of the issue class. Security embargoes no longer buy us the time they were designed to, and so we need to do either private patch development, or continuous public shipping with better release automation, and/or virtual patching/redeployments at the protocol layer to protect endpoints while the real fix winds its way through human review and packaging.

Some interesting responses to my post:

  • Thomas Depierre argued that nothing has structurally changed, as the ecosystem was already so target-rich that embargoes weren't buying much anyway, though I do think that chaining an exploit within seconds of a disclosure is a genuinely new capability.
  • Török Edwin suggested that once a package name and vulnerability class are public, we should assume the bug is rediscoverable and publish the advisory immediately, referencing the fix commit even before a release exists.
  • Andrew Nesbitt wasted no time and has started on an OCaml runner profile for the Scrutineer scanning I mentioned in the post.
  • Justin Cormack pointed me at OpenAI's Trusted Access for Cyber programme, which he's found lightweight to use. I duly tried it but the individual verification flow rejects my cam.ac.uk account on the grounds that it "isn't available when you use a company, government, or education email address". Argh!

3 OCaml and OxCaml releases

3.1 We need humans behind opam packages

I reviewed and merged Romain Calascibetta's opam-repository#30367 which added a new governance policy to opam-repository that "package contributor accounts should have a human behind them". The guidelines are:

  • A new package proposal may be submitted from a bot account, but the PR must be tagged with a human contact so maintainers know who to talk to.
  • Subsequent discussion should avoid excessive noise such as large LLM-generated responses or automated triage logs.
  • Any machine-generated comment on a package publication PR must be explicitly identified as such.
  • When human reviewers ask questions or give guidance, they must be met with human replies.

The opam repository is somewhat distinct in the world of package management in that we have a team of humans who review and merge new package submissions. A small but growing number of these submissions come from projects with bot-based release procedures, and in several cases I've had to dig out who the responsible person actually is as they don't see our reviews.

I think this sort of guidance supersedes my AI disclosure policy proposal from earlier in the year, which was a technical solution to a governance problem.

3.2 Prometheus 2.0, now with eio

prometheus v2.0 is now out two weeks after 1.4 and adds eio support for Mark Elvers to use in our infra. Thomas Leonard found that testing 1.4 with opam-repo-ci broke more programs than expected. We therefore switched to using mirage-mtime to portably measure time spans (prometheus#70). The opam-repository PR is #30535.

3.3 Eio 1.5 also released with better Windows support

Thomas Leonard also released Eio 1.5. The headline features are the support for Windows paths that I contributed, and the ability to set socket options before connecting (eio#875). After that, I also reviewed Patrick Ferris's eio#923 which adds environment variable support to Eio.

I'm still chewing on ocaml-uring#153 that switches the buffer type to bytes instead of bigarray/cstruct. I have a glorious hack to keep compatibility with existing bigarray users via a fake "managed" bigarray that aliases the underlying bytes without copying.

The bigarray is allocated as a managed subarray with a hand-built proxy whose data pointer is NULL, so the runtime refcounts every derived slice but never tries to free() the bytes, and also a recursive finaliser closure that captures the bytes and re-registers itself until that refcount drains. This ties the bigarray proxy to the bytes as long as any bigarray view (such as a subslice) exists. This only works because the backing bytes is kept large enough that the OCaml 5 runtime will never move it, and there's not much performance impact if we never touch the bigarray view. Let's see how this holds up in the next few months...

References

[1]Madhavapeddy (2026). A Proposal for Voluntary AI Disclosure in OCaml Code. 10.59350/cxypn-ysv27
[2]Feng et al (2026). TESSERA v2: Scaling Pixel-wise Earth Foundation Models. arXiv. 10.48550/arXiv.2607.03949
[3]Madhavapeddy (2026). Just a rumour of a bug is enough to find a security exploit these days. 10.59350/tngsm-6rx23
[4]Kusupati et al (2024). Matryoshka Representation Learning. arXiv. 10.48550/arXiv.2205.13147