OCaml Weekly News

The original ppx_deriving can't support Melange: it predates dune's Melange integration — it is distributed through findlib META files, and its generated code depends on a runtime library that isn't built in Melange mode. Melange can only link libraries that dune builds for it, so common patterns like \[@@deriving eq, show\] were off the table when writing frontend OCaml.

ppx_deriving_melange fills that gap: same derivers, same naming conventions and attributes, implemented on ppxlib and tested against Melange — and its generated code is self-contained, so nothing extra needs to link into your bundle.

A key use case is universal code — libraries compiled both natively and to JavaScript. Put your shared types in a library with (modes :standard melange), derive once, and the exact same equal~/~compare~/~show functions run on the server and in the browser. (This is how the project tests itself: one test-case library exercised by OUnit natively and by node on the Melange side.)

type user = {

  name : string;

  roles : string list;

}

[@@deriving eq, ord, show]



(* generates:

   val equal_user : user -> user -> bool

   val compare_user : user -> user -> int

   val pp_user : Format.formatter -> user -> unit

   val show_user : user -> string *)

Supported derivers in 0.1.0: eq, iter, map, ord, and show, following the native ppx_deriving conventions — including the equal, compare, and printer attribute overrides, the with_path option for show, tuples, records, (polymorphic) variants, options, lists, arrays, results, type parameters, and recursive type groups. The README documents the exact supported scope of each deriver.

Two design points worth calling out:

• Self-contained generated code. There is no runtime library: the generated functions only use the stdlib, so the ppx is a build-time dependency only.
• Bundle-size-aware show. Melange compiles Stdlib.Format into a lot of JavaScript, so show builds its string directly and only falls back to Format where the type requires it (custom printers, etc.). Code that only calls show doesn't pull Format into your bundle; pp stays fully Format-based and native-compatible.

Some ppx_deriving derivers aren't implemented yet (enum, fold, make, …), and a few type shapes are out of scope for now (ref, lazy_t, nativeint, functor-applied types). If you need one of these — or hit anything that behaves differently from native ppx_deriving — please open an issue; that's exactly the feedback that will drive what gets built next.

opam install ppx_deriving_melange

(library

 (name my_frontend_lib)

 (modes melange)

 (preprocess

  (pps ppx_deriving_melange)))

Thanks to the ppx_deriving authors — this project follows their design and behavior closely, and includes their license attribution — and to davesnx for reviews and encouragement along the way.

Feedback, issues, and deriver requests very welcome!

The public vulnerability database (https://github.com/ocaml/security-advisories) is established, and filled as well with old security advisories (from the MirageOS project, etc.). There is tooling via CI which generates a branch "generated-osv", which is a source for the Open Source Vulnerability database (https://osv.dev), run by Google. The direct link for all security advisories of the OCaml Security team is here.

The tooling is available from https://github.com/hannesm/advisories.

Another utility to check your "opam switch" for installed vulnerable packages (using the above mentioned vulnerability database), has been developed - available at https://github.com/hannesm/opam-audit.

On March 19th a public OCaml security meeting took place with 10 attendees. The meeting notes are available at https://pad.data.coop/7-Ic5rG6ToynsW02hJsndg

The Security Team proposed to make the immutability policy stricter (see https://github.com/ocaml/opam-repository/pull/29072) - which has been merged. So, any published opam package must not modify its sources (change tarball, add patches, modify build instructions, …). Instead, a new version must be published. This makes the package URL (https://github.com/package-url/purl-spec) sensible and point to a precise source.

A call for contributions was opened until end of March 2026. The Security Team is impressed by the amount and quality of the proposals. Evaluation and finding funding for proposals is still ongoing. We have some preliminary decisions and will reach out to the applicants by the end of July 2026.

So far, there have been 10 advisories (OSEC-2026-01 until OSEC-2026-10) published, and some more are worked on. Our primary communication channel is email, and we reach out to reports that we received GitHub by email. A public mailing list is available where security advisories are announced.

They range from issues in the OCaml runtime (Marshal buffer over-read OSEC-2026-01 CVE-2026-28364, Bigarray.reshape interger overflow OSEC-2026-04 CVE-2026-34353, command injection on Windows via filename OSEC-2026-05 CVE-2026-41083), opam sandbox escape (OSEC-2026-03 CVE-2026-41082, OSEC-2026-10 CVE-2026-57825), insufficient certificate property checks (in tls, OSEC-2026-06 CVE-2026-45388, OSEC-2026-07 CVE-2026-45389), path traversal (in tar, OSEC-2026-08 CVE-2026-45390), memory exhaustion (unbounded memory usage in arp, OSEC-2026-02, infinite loop in albatross-console, OSEC-2026-09).

The variety of reporters - 8 different people in 10 reports - is amazing. Thanks to all reporters, as well as the upstream developers. It has been a pleasure to coordinate the vulnerabilities.

The Security Team also hopes to publish security guides for OCaml programmers and project maintainers.

The Security Team is an initiative of the OCaml Software Foundation and is grateful to the OCSF and its sponsors for their support.

This living document aims to set out and explain the current status and the planned trajectory of our ongoing work. It should help to convey both what what we are working on and why we think it is important. It is not heavy on technical details, but aims to give a high level view of the project trajectory. For technical details, please click thru to the tracking issues: they are are in varying stages of discovery, but some are very well developed or provide a view into the history of completed work on the milestone.

We will keep this document up to date and it will be revised as needed, to keep our projections in line with our emerging understanding, and to incorporate feedback and guidance from interested stakeholders.

As you will see on the roadmap, a substantial course of work led by @Alizter, and supported by @ElectreAAS (among others), has made the relocatable compiler available by default in dune package management, building on even more substantial prior work by @dra27's. This makes use of David's overlay compiler packages to provide relocatability for previous recent compiler versions.

In my personal experience, this has made a decisive improvement in the the UX of setting up projects with dune package management, and came along with many additional fixes improving opam package compatibility.

As a very welcome bonus, dune package management now supports the installation of packages that use symlinks in their sources!

Please feel free to share any input or raise any questions! Input can be shared in this thread, or through our documented channels for feedback.

• :money_bag: For people using the shell hooks, this release changed the way PATH is kept up-to-date from opam taking priority over any other elements of PATH by making sure to always be in front, to replacing the directory managed by opam in-place, keeping the order asked by the user. To benefit from this, make sure opam init --reinit -ni was ran once after upgrading to this version (automatically done by our install script if it detects an existing opam installation). (#6859, #6815). Thanks to @gridbugs for this contribution.
• :wastebasket: Reduce the disk space usage of opam by removing the build directory as soon as possible and removing redundant archive caches. While the disk usage used by opam can be reduced over time while simply reinstalling packages, you can liberate some free GB in one go using opam clean --all-switches. (#6440, #4056, #5448)
• :high_speed_train: Improve performance drastically on certain file-systems (e.g. NTFS on Windows or IO constrained machines) by changing the format HTTP repositories such as opam.ocaml.org are stored in internally. (#6625, #5346, #5741, #5648, #5484, #5559, #3050, #6974).
• :envelope_with_arrow: Add root and rootexec sections to .install files to install files from the root prefix (#6938, #6919). Thanks to @WardBrian for this contribution.
• :woman_technologist: Add a new --ignore-available-on argument to allow ignoring the available: field of certain packages (#6836, #5283). Thanks once-again to @WardBrian for this contribution.
• :ocean: Many more UI additions and improvements, bug fixes, …

:open_book: You can read our blog post for more information about these changes and more, and for even more details you can take a look at the release note or the changelog.

The upgrade instructions are unchanged:

For Unix systems

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

or from PowerShell for Windows systems

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

Please report any issues to the bug-tracker.

Happy hacking, <> <> The opam team <> <> :camel:

— Special thanks to the Haematology department and Bone Marrow Transplant Unit of the NHS Greater Glasgow for making this release possible <3