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=fTJ9uTv+; 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]) by plum.tunbury.org (Postfix) with ESMTP id 9722F40099 for ; Tue, 25 Aug 2026 07:36:50 +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=EP7XnvyW8keNWhmwNvUc4OR8UzKdfrQRy7txr2mC4Hw=; b=fTJ9uTv+2DyNuAijYoyaJApEB8Aw2zAXTv1rnCUofk/ZfI/fNyDuE08j 3/xSAQkuCMYUNXioXMtFzKFKBJVkOf/6VajewKL6FQidkgJ1+JYLx1wt7 9PeNvsMgQVOnlYbVingGMQy6r8In0WxYpQfA4EbKemmP23FrjFCYub71H 8=; X-CSE-ConnectionGUID: LSJhPTl5QCav6Pd75V6LbQ== X-CSE-MsgGUID: MeEYtO8gRA+zNY/LVoFGpQ== 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.25,242,1779141600"; d="asc'?scan'208,217";a="291386094" Received: from prod-sympa-app.inria.fr ([128.93.162.27]) by mail2-relais-roc.national.inria.fr with ESMTP; 25 Aug 2026 09:36:48 +0200 Received: by prod-sympa-app.inria.fr (Postfix, from userid 990) id 37C8F81C3F; Tue, 25 Aug 2026 09:36:48 +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 A9A7081C33 for ; Tue, 25 Aug 2026 09:36:37 +0200 (CEST) X-CSE-ConnectionGUID: 61T8hUZqTXOyxw9L8hPUfQ== X-CSE-MsgGUID: GSGbIVsNQRW5TMgK0JWXbA== IronPort-SDR: 6a8d4603_vg+Ad1ZJrgq7xivWbkWfhLcUUxoaoLJW2WES5YcSDod6gHy 6oZD77zNPh62e6kvO00+Ut7jWoAXiVRafGk/KTw== X-ThreatScanner-Verdict: Negative X-IPAS-Result: =?us-ascii?q?A0HUBwDYRI1qhSIeaIFUBoQWgQQbAW5fGRoHCEkDhFWDT?= =?us-ascii?q?44kgRaQN4I8hzCBEA2BXIErFiECDgcBAwEIBS4BBRoBAgQBAQECAQIBhDhGA?= =?us-ascii?q?o1tAh8GAQQ0EwECBAMCAwEBAQEBAQEBAQEBCwEBAQQBAQECAQECBAMBAQEBA?= =?us-ascii?q?hABAQEBQEmGTw2CRRk4cWAEAwY4AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAgQIARmBBQEIBAYTAQElExgjAxQBBgMCEQE1A?= =?us-ascii?q?wETAQkJGoJZDwGCIAICUAMFDAajLJsjen8zgQGCDAEBBoEIPgIMAgIDGCUB2?= =?us-ascii?q?hqBYAkDBhSBIRiBWIQZglEPDQEqSWoCAQKEUQmEOCcPgVVEgRQBNYI+B2+CA?= =?us-ascii?q?kEeAQEBARiBDAQUAQEGAQEIATwJgyWCaoImgQwbgSE8Mh4YAQ+BVIZtA4ghg?= =?us-ascii?q?kIsAVUTFwsHBV6BCAMqLy1uMh2BIz4XNVgbBgWBHYEohBAjGTZ8gQlegSspY?= =?us-ascii?q?RIXgQmCBwKCWoIFAgFJQw4HRyILbT03FBmNLxAhDYFFSRkfgUgTJA4KLggVF?= =?us-ascii?q?BMPDTUBCgkWAQENEwI2GRQTAxYDHQkFBgMQEAEKGQYNBQQCLY0QhTYUEhYqA?= =?us-ascii?q?510k1mBCjQHhCGBYAYMiEdDgSaLZoJOh1OEBI0UhwOSUSKYZiOJXoEmCYFvH?= =?us-ascii?q?0yVNCwEBBiFOYF/I4ErFggMBzMaMEOCZwkWMRwPgRuRCEF9gxo7xwhCNQIBA?= =?us-ascii?q?QIIMQcCBw8ChWsBAWeLITJrAWABAQ?= IronPort-PHdr: A9a23:/RJpsRT22ThwiS2eE3W2H5E+8NpsoniQAWYlg6HPa5pwe6iut67vI FbYra00ygOSA8ODsrkd17OI7+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4qoL3O+B9PRKxIAI cJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3OgV6PPn6FZDPhMqrye+y54fTYwJVjzahfL9+N hq7oAvQu8UMnYduN6k9xgbGr3dVeulbyn5jKE6OkRr7+sq/85lv/jhKtfk87cBAS6L6f6o5T bxcEjsrNn0+6dPouxfeUwaB/2MQXGoOnBVHGgTI8h70UIrpviT1quRy1i+aPdbrTb8vQjSt8 71rSB7zhygZMTMy7XzahdZxjKJfpxKhugB/zovJa4ybKPZyYqXQds4aSWRCWMZRSS1BApi9b 4QUC+oOI/tTrof6p1sUsBS+HhSnCOfhxzNUg3P727Ax3eY8HgHcxAEuH8wAvmnaotv2O6gdT fu4zKbUwTjZdf5axSvx5YrOfxs8of+MR7Vwcc/JxEQzEwPKlFOQopH4MTyJ1uQNtmmb7/Z8V emyjGMosQVxrSKpxss2kYnGmoIVylXF9SVl3IY4PsW4SEl/Yd+kDJtfqT2VN4twQsMjWmFop Tg1xqcBuZ6hcygH0ZIqzAPQZPKbaYaH+A7jVPqPLjdignJoYLyxihSy/EavxePwSsa63VlEo ydHjNXBtHAD2gDc5MSbRfVw/Umv1CuR2g3d5e9KL0Q5mKnFJ5AuwLM+mZUevETFEyTrlkv2i 6qWeV8l+uiu8+nneqvppoOdN49olA7+KqMumsm6AesmKAQOWXaU+fik2L3s/E35XLVKjuAtn aXDrJ/aIsEbqra+Aw9OzIYv8QuwACm40NgAmnkIMEhKeBeDj4TzPFHOOv/4Ae+jjFSsijhrw f/GMaP6ApnXK3jMja/tfbFh5EFGzQozycpT64hTCrEbL/L/Qk7xtNrDDh8lKQO0x+LnBM9m1 oMeQW6PDLWWMLnWsV+P6OMjOfSDa5ELuDrlLvgq/f/ujXkjlV8YeamlxZQXaHGkHvRmPkWWe mDgjs0dHmcNuwoyVO3qiFuYUT5SfXm+Raw85is9BYm7DonDXpigjKGf0Cq/BJFae3xKB1+WH Xrma4mIQfkBZS2KLsN8nDEISKKtR5Eh2ByhrgP21adrIvDK9iAXsZ/u0sV+6ffJmhEo7zN0C tyQ02GTQGFwmWMFXzo23a9irUBn0leD1qx4gvxEFdNN+/xJUgE6NZ/Fz+xnFd/+QAXBfs2GS Fq+Q9WmBy8+Ts4pztMTfUpwH8+ugg3f0yelGbMYmaCHCIY6/6/Tx3TxItxyy3fC1KkvlVkmR c5POHW7iKBj6gbfG5bEnFmFmam2cqoRxC/D+nqbwGqWu0FYVA5xUbnbUn8DZkvWq9X55lrfT 7CwE7gnNRFBycGaJ6RQbt3ml1NGSO34ONvCY2KxnmawBQqUxr6Xd4XqfHgd3CPBB0caiAAf5 3OGOAcxByu7pGLeFjNuGUr1Y0zw6el+tG+7Tkgswg6WdUJh0r619gcRhfydUPMTwqkJuDwhq jVxBFayxcjaC9uGpwp7faVTe8kx4Fld1W7BsQxyJYSvL7p+iV4GbwR3o0Tu2g1qBolYnsgls nQqwgloJ6+A0F1PayuU3YruNb3JKWf85giia6vZ213DytqW4qAP6PA4qlX/og6mCkoi83Nm0 9lMznuT+I/GDA0IUZL+Sko46ht6p7DfYiQl/43a2nNjP7eovDLe3dwlHPYqyhO6cNdFLKyJD Bf8HdQCCcahMOAqgECpbhwcMe5I6KM6It6oe+Od2K6zMuZvhDKmgnpD4IB6yk+C7TZxRPPV0 cVN//bNlA+YUX202FO+tOjzhoYCYzwOSC73wiHhAMtVZ7ZuVYcNE2anZcOtlftkgJu4cnpR8 haYDFMD2dO1MU6ba1X7mxZb1UEWvWCPgSy83iB5mDEvr7OC0WrJ2eu0J0lPAXJCWGQ31QSkG oOzld1PBxDAh2kBkRKk4R2/3K1HvOFkKHGVR05Ufi/wJmUkU62qt7PEbdQcoIgwv3BxV+KxK UufVqa7uwEThirnFm0Y3zs7cjC2pr3hmBhrlG+WLHBytWfUP8ZqykSX/8TSEMZYxSFOXyxkk X/SD1m4McOu+ICvrayb5+uEXEf0eaYGaS7v3J+Nvyu95HR3DFu4hf/mk9nuF04h2i/+1sV2f S/PsRD3b5Kt0viqd+V9cRogH0fyvvJzAZo2iY4snNcQ1Hwd042S5mYCmHzvPM9z3LKnKmIKQ S8XztXV5gn8xUAlKWiGr27gflOaxMYpJ9yzY2dNnzk489gPE6CMqrpNgSpypFO86wPXe/l02 DkHm7Mo7zYBjucFtRBIrG3VC60OHUReIS3nlgiZp9G4oqJNYW+zcL+2nENglNGlBbuGr0lSQ nH8MpslGCZx6I14PjeumDX67ojiPsLbbdcSqgG8ixDEnvRYI5I3l+MXiGxgI2289Xwpxugnj AB/iImgtdviSS0l96a4DxhEczztMppJq3e01foYxZ7QhNz8e/cpUi8GV5bpU/+yRTcbtPC8c h2LDCV5sXCDX7zWAQ6Y7k5i6XPJCZGicX+Ndxx7hZ1vQgeQIEtHjUUaRjI/y9QCLDvykcfbe 2IsyQtE/ln8uwdBweJuNgDiXyHYvgj9YzM9Tt6EJxpT7x1ez03SLMqV4/k1Gn1IuJq7o0beT w7TLxQNFmwPVkGeUhrqOrCoo8LL8+2ZGvaWN/zKcKmDouxYVu6VyNSoyIQsrFPufo2fe3JlC fM8wE9KW3t0Tt/Ylzs4QCsSjyvRbsSfqX9Q4wVPp9ukuLTuUQPrvs6UDqdKdM5o41awiLuCM OiZgGB4LyxZ39UC3y2AxL8a1V8UwyZgElvlWY86jnaYR5jbv/p4NEsDbCdiKMZD76Q9xxRAf 8nBhYb80rd+yOU+C1JESUDJkMa0Y8cHOCe4aEOBA1yEUdbObTHG2MD4Z6qgRKYY1b8F8UTo5 XDASwm4YnyKjHHxWgqqMP1QgS3TJxFYtIynM3MPQSDiQN/gdhynIYpyhDwyz6czgyCCPmodP D5gNkJV++TKvGUB2qk5QDQHtSY2SIvM0zyU5OTZNJsM5P5iAyAv0vlf/Gx/0LxNqidNWP1yn iLW6N9ouVCv1OeVmV8FGFJDrChGgIWTsABsI6Lco9N7Y02cqRk35kDFJC9fv9xhG8HisKBWy 8HSmeT0MjgX+tbd+40HDMjRKd6bGHAmLBziFSWSCVcVCzmxOiuM4i4V2OHX7XCTopUg/9LXo qFWH7RhX3lgOchPEkNhDcAPK5dxXyo5nPiclsFd7H63ql/KT8Vfv4zbfviVHPPkJS3fiOVUI RwSzvmrSOZbfp2+0EtkZF5gmY3MEEeFRtFBrBpqaQosqVlM+nxzHSUjnljoYQS37DoPBOa5y 1Qo3xBmb71np1KOqx8nY0DHrywqnAwtlMX51HqPJSXpIv74HoBOV3it7Rl3a8unBV0tK1bu1 Q9lLGuWHugAyeI4KSYw0EmH5P4tUbYfTLUYMk5Jg6jNPrN2ixIF8nrvhk5fu7mfUcM7xldzf cb+piAf0g8+PoxrKfOAdvESqzoYzuGPpnH6jLhpmV1CfkpVojrAKXIEtR5aaeJ4K3j3orM0o UmLnz8JEIQVf8IjuekitkY0OuDbijnlz6YGMUepceqWM6KevWHE08+OWFI5kE0SxQFJ+r1/0 MFrdETxNQhn1LyKCxEALtbPMylQf5MU7H/XbDqDuuXLwItoMsO6DO+gQeKVtakSi16pB05wR dVKt5xdWML0lhqEZc78SdxNgQ0g/gHqOEmIALxSdRSHnS1G68CzwZlr3JVMczEQBWIueS6z5 7vRukormK/aBoZwOy9GGNBccClqC6jY02ZDsn9NDSe6yLccwQmGtHrnozjISSL7d5xlbeuVY hVlDJe3/y8++u64kw2ykN2WKmfkONBlotKK5/kdosPNMMlvFex2iUz5zqZjEmStV3/THNW1I ZnpdoRqasb7X3++W1r5kDk1SsbtIP6nKbWOigzzA4MIoM+cxj9pZqrfXnkOXgx9oe0O/vc2f QoYf58yegLlrSw7J/X5OACcw8mjSGarKCJLQr9Y1+rwNNk1h2I8K+S9znUnVJQzyeK6pFUMS J89hRbb3f+/ZoNaXHu7CjlHdg7IvyZ8i3l5O7N43LIk2B2R+wp5UXjDZKlzZWdDpd15GV6CP SA8FD8jX1HFxYOLpweo2/p6F8R1ldFJ1+ZIqz774o+ZZyijCvXDQXD9qy0kfMQrqK13MJX+L 42BrpyMxlQ3rbHVolTDSCm+BuZXkdhWITtFTb9Pg253YKQ7 IronPort-Data: A9a23:BGKl4KxQ75WcrHTFaMt6t+cBzSrEfRIJ4+MujC+fZmQN5Y8a5oE1v iFGDjfXfrrIN3ykOIpG3L7GpE4AuJ6AytZgGQNuri1kEnkX+ZuaD4zEdEr7b3PCfpedFh44t pRHZtKZfJlvHyHQ9k2jbOO79iNw2f+FGrHwVoYoVswJqSpMEU/N3jo+xb5RbvdUvOWE7yOxV fLa/cHUZVb/0TJ5amwZuvmJ8ktl7f7+5D5J4QAwa6wWtw6CzilEB582G/2NIiqjSOG4PMbqH reZlOnREkDxpkp2VIv9yt4XVmVQH9Y+6CDX0iI+t5CK20YE/mpulP5iapLwUG8P4x2Rhdd91 d5RgpK5TAYtL8Xklf8UO/ViO3gW0ZZupvmdfBBTjeTJlxeYKyu2nq03ZK0LFdRwFthfUTkmG cMwc2hlgiCr34qe3L+9Q+9wscUvROGDFJ8foHxp0QbCBv8gR53ZK42SjTOP9GpYamhmRJ4yV uJBAdZdRE2ojy5nYz/7PKkDcNKA2hETRRUI8QPP/fJfD1/7l2Sd2JC1WDbcl0fjqc99xi50r Uqfl4j1741z2HVyBlNp/1r17tIjkx8XV6pMTYHo9sNYmWGj4X0DF0wyBVuDnPeA3xvWt9J3c yT4+wIrvfF07EuvX8XwVB2+oWeZs1gbQdU4/+8SsVvcjPOMv0DCXi5fElata/R+3CMybQcQ7 QfclOniIGlAi+iNTnaM6rqfrTWzIDUYa2gYanoNSQIDpcLooIQykg7nRNF+FqW4lZvwRSG2x CqFxMQ7r+xO0Z9XjvXnpzgrhRqDnbfDbzAuwDztYT+ZywxaPKyaV4aBvA2zAfFod9vFEALe5 BDogfO25+kLCdSJlTeRaP4cGamgofeDKjzVx1B1d6TN7Byo6yflZYdU8S1zL0dvM98ZdHnue kC7VR5tCIF7YiKWPa9KUZuNO+M73bexMYTlbs3aV48bCnRuTzNr6h2Ccma+5QjQfKUElLFmf 4+cddewAH0aD6V+0TfwQP0SuVPK+szc7T2OLXwY5035uVZ7WJJzYexeWLdpRrtihJ5oWC2Pr 75i2zKikn2zqtESnRU7AaZIcAxUdidjbXwHg8FcceqOahJhHHA9BvTRx7I4ZoEtkrxOnf+gw 0xRrnRwkQKl7VWecFXiQi44MtvHA80gxU/XyAR3Zj5ELVB4Ot73tM/ytvIfIdEayQCU5aUqF qFfIJTeWKgnp/au0211UKQRZbdKLHyD7T9i9QL/CNTmV8c4F1abycyuZQb16igFAwy+sMZ08 fXq1RrWTdBHD05uBdrfIqDnhV6gn2kvqMQrVWvxI/5XZBrN9qpuIHfPlfMZGZwHBijC4Tq47 DyoJykki9PDmbJoz+mRt5u499+oN8BcAntlG3Lq6OfqFCvCoUum74xycMeJWjH/aF7w3bqaW sNu/qmkYcdeuQdBnNtnHoZRyZNk58bml5ED/D85An7OZAWaNaNgKHjbz/gVtrFE9oUBgCSUR E6wp9toCZCUMv/fTHoUdRsXf8WY9PQugjKJx+8EEEb7wy5W/bS8TkRZOSeXuhFdNLdYNIAEw /8rncwrtzyElRshN+iZghBu92ijKmIKV4MlvMo4BLDHpxUKyFYYR7DhEQ7zvY+ybutTPnkQI jO7gLTIg5JezBHgd1sxDX384vpPt68RuRxlzE4wGHrRo4Dr3sQI5Rx29Sg7ai93zR8diuJ6B TVNBn1PfK6L+29ludhHU2WSADp+PRy++HHq6l43hWbcHliJVGvMETUHAtyz3nslqkBSQjsK2 4uj6jfBcS3rd8TPzCcNSRZbi/j8f+dQqCzGuu6aRvqgIbdrQADYkpePZHUJoSTJGckeplPKj sg08fdSaZ/UDz8xoao6AbmVxZAWYg6OBGgac85H+6kMGXHQRwyv02OsLWGwZcJ/CPjY+mCoC 8FVB5xuVjbv8A2svzwkFao3DLssp8EQ5f0GYaHOCVMdlrmi8gpSr5Pb8xbhiF8RQ9lBldg3L qXTfWmgFlO8qGR1mWiXiuV5IUu9PMc5YTPj0NCP8OkmE4wJtMduexoQ1pq2p3CkDxt1zSmLv Q/sZ77k8MI68N5Cx7DTK6RkAxm4DfjRV+7SqQC6jIloXOP1aMzLs1sYl0njMwFoJoAuYtVQl 4mWkdvJzUjA7acXUWfYpsG7LJN3x/6OBchZDsGmC0Nhv3qmeNTt6B496WyHOcR3sNdC1PKGG Sq8SuWNLOAwZfkM5Ud7SSZkFzQlN5/WdYbl/CO0kOSNAEMS0CvBN9KWykXqZmB6KA4NFYbPN VPpsKyI4dpnqNxAKTUbDat2XpNXHl3qdvY+fO3PsR2dX3iak3KZm77YjRF7wyr6OnqFN8fYy 5jqaAXfWjKwsY6R1N15io18hQIWB3BDmtsNfloR1tp1qjKiBksEELgtCooHAZRqjSDC7pH0S zXTZm8ECy+mfzB7XTjjwdbkBCGzO/cvP4rnGzkX4E+kUSe6K4eeCr9H9C07wXNXeCPm/d63O +Ml5Xz8ERig8K5HHd9JyKSAvt5m4ffGylYj20P3yZXyCilDJ4Q67iVqGQ4VWBHXF83Iql7wG lE0YmJ5W2C+d1/6FJdxWnxSGSxBhgjV8RcTUX6tzurc6qKh988R+M2nbqu3mvcGYd8RLbEDe WLvSiHfqyqK03gUou0yt8hvnaZwDumRE9OnKLP4AzcfhLy09n9tKvZqcfDjly3+0FU3/5Lhe jiQD7wWAVTcblhW3KyKxA4J/ZNoT39KCCvG5OI6jSGTigQ3lrA1ZDDzpD8X67mpw0Qgg6mca D0VcUCarkbQsWf04z5kuZz3Y3SZVNoJGyCsvj8AF/vPf9TFdIOZPKhm11Am2tlR9nxd24gSc 7yeuzn4FERLQQvXtz3ZcBwljnSLYlvP9snvS1Mkwf6zKuaN6Q== IronPort-HdrOrdr: A9a23:Dp+d4KyFOFtZFN3po0ALKrPw071zdoMgy1knxilNoHxuGfBw9v re+cjzsCWYtN9/Yh8dcK+7SdS9qB/nlaKdmLNhWotKBTOWw1dAT7sJ0WKB+VLd8kTFn4Yw6U 5dSdkcNDSaNzlHZKjBkWuFOudl5P6m3ZrAv5an854Ud3ARV0nAhD0JdjqzAwlzQ01HCKcoDZ b03LsimxOwPXARKsO8G3kLT4H41qT2vYOjZRkcDQc79Q/mt0LP1ILH X-Talos-CUID: 9a23:7M36o2DpYs6VwLL6E3c+yB4UJ/I8Tk363WfPcmvoCV5URoTAHA== X-Talos-MUID: =?us-ascii?q?9a23=3A0KqOZQ7k9ltM3v+VXqcJXUy3xoxH2IukKX4Wt6w?= =?us-ascii?q?8hJS4ECNTYxWivD6eF9o=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.25,242,1779141600"; d="asc'?scan'208,217";a="154941842" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown X-MGA-submission: =?us-ascii?q?MDHRrR98t4Z3VmhbGQh5J3h4Z+Hd0sl/EeQ6OL?= =?us-ascii?q?2a0KlnbGFiHL6xcW0Z0kJtyY0SbD/poY5BkAQasgN4H5wqnTZ1iaqe9T?= =?us-ascii?q?vob5uSQN3vH5jrFe2d/DvN7CmCaw/p0A7uiifj7/Lkf+n0BX4WCa/dQB?= =?us-ascii?q?ExFO347/XRO9oQizslVWrfMg=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; 25 Aug 2026 09:36:36 +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 E832B1A5C6; Tue, 25 Aug 2026 09:36:34 +0200 (CEST) From: Alan Schmitt To: "lwn" , caml-list@inria.fr Date: Tue, 25 Aug 2026 09:36:32 +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 Aug 25 09:36:35 2026 +0200 (CEST)) X-Spam-Flag: Unsure, tests=bogofilter, spamicity=0.499858, queueID=2657A1A5C8 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: 19566 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 August 18 to 25, 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 OSEC-2026-16: cohttp: path traversal Cascade: A Typed CSS Toolkit in OCaml YAMLx 0.5.0 + odds things about the project Opam repository package contributors should have a human behind them Cohttp 6.3.0 released (OSEC-2026-16) opam 2.6.0~alpha1 Jane Street Libraries (base/core/async/etc) with 5.5 OCaml running on a 1960s UNIVAC 1219B Old CWN OSEC-2026-16: cohttp: path traversal =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=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, we just published a security advisory for cohttp - please find it below (and as usual 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-16 =E2=94=82 modified: "2026-08-20T18:15:00Z" =E2=94=82 published: "2026-08-20T18:15:00Z" =E2=94=82 severity: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N" =E2=94=82 severity_score: "7.5 (High)" =E2=94=82 affected: "cohttp" {< "6.3.0"} =E2=94=82 events: [ =E2=94=82 [ =E2=94=82 git "https://github.com/mirage/ocaml-cohttp.git" [ =E2=94=82 [fixed "5f5a65ec3289c1cd8072bdf0ef22c181b4f11356"] =E2=94=82 ] =E2=94=82 ] =E2=94=82 ] =E2=94=82 credits: [ =E2=94=82 [reporter "Sapphire Livingstone"] =E2=94=82 [remediation_developer "Sapphire Livingstone"] =E2=94=82 [remediation_developer "Anil Madhavapeddy"] =E2=94=82 [remediation_reviewer "Anil Madhavapeddy"] =E2=94=82 [remediation_reviewer "Michael Dales"] =E2=94=82 [remediation_reviewer "Edwin Torok"] =E2=94=82 [remediation_reviewer "Patrick Ferris"] =E2=94=82 [coordinator "Hannes Mehnert"] =E2=94=82 ] =E2=94=82 cwe: [ CWE-22 ] =E2=94=82 affected_bindings: [ =E2=94=82 "Cohttp.Path.resolve_local_file" =E2=94=82 "Cohttp_async.Server.resolve_local_file" =E2=94=82 "Cohttp_lwt_unix.Server.resolve_file" =E2=94=82 "Cohttp_lwt.Make().resolve_local_file" =E2=94=82 ] =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Path traversal in Cohttp.Path.resolve_local_file =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 The issue is that the function normalizes the URI path before percent decoding it: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let resolve_local_file ~docroot ~uri =3D =E2=94=82=20 =E2=94=82 let path =3D Uri.(pct_decode (path (resolve "http" (of_strin= g "/")=20 =E2=94=82 uri))) in =E2=94=82=20 =E2=94=82 ... =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Because `%2f' is decoded after Uri.resolve, encoded separators survive dot-segment normalization. For example, a request path like: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 /static/..%2f..%2f..%2fetc/passwd =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 is normalized as a single encoded segment, then decoded into: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 /static/../../../etc/passwd =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 afterwards. 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 Aug 11th 2026: report to security@ocaml.org =E2=80=A2 Aug 14th 2026: PR published on =E2=80=A2 Aug 20th 2026: fix released in v6.3.0 Cascade: A Typed CSS Toolkit in 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 Archive: Continuing this thread, Thomas Gazagnaire 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=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 I have just released [cascade] 1.1.0 (which was just merged in opam) which improves the diff output quite a bit (especially on CSS sheets that user layers, containers, medias or other fancy structural elements) and adds something I wanted to rely on for a long time but for some reasons didn't think about adding earlier: a differential testing harness to test how a (headless) browser interpret a random CSS sheet on optimized vs. non-optimized mode. This allowed me to find quite a few issues (most of them as corner cases, but some were a bit embarassing) and explain the size of the [CHANGELOG]. Happy to get any feedback on it, especially if the [documentation] is useful at all (I have tried without success to get some magic odoc runes to embed runnable CSS fragments in there, is this possible at all?) [cascade] [CHANGELOG] [documentation] YAMLx 0.5.0 + odds things about the project =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=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: Martin Jambon 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 I just released [YAMLx] 0.5.0 ([release notes]) which provides a few fixes and improvements since the [original announcement in April]. YAMLx is a pure-OCaml library implementing the complex YAML 1.1 and 1.2 specifications. It aims to provide a complete yet convenient user interface to manipulate data in this popular format. Beyond the boring announcement, this is an opportunity for me to bring your attention (again?) to the unusual aspects of the YAMLx project. It is sacrilegious and experimental along 3 main axes: [YAMLx] [release notes] [original announcement in April] AI use =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 Most of the implementation is AI-generated (~10K lines). =E2=80=A2 The interfaces are mostly human-crafted (~800 lines). Authorship model =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=80=A2 The project has only one single traditional contributor. =E2=80=A2 Contributions are encouraged in the form of bug reports and det= ailed feature requests. =E2=80=A2 The project doesn't take external code contributions. Funding =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 The library is available for free under a strong copyleft licen= se (AGPL). =E2=80=A2 A one-time contribution ($500) gets your organization a perpetu= al commercial license. =E2=80=A2 Past the funding threshold ($5,000), everyone will get a permis= sive license for free (ISC). =E2=80=94 I'm happy to go over the motivations for these choices. Just as= k. Opam repository package contributors should have a human behind them =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=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: Anil Madhavapeddy 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 Dear all, I wanted to draw your attention to a new bit of [opam-repository contribution guidance] that we have just included. `14.' Package contributors accounts should have a human behind them The review work by the maintainers of `opam-repository' is carried out by humans, and we need to have a contact to respond to our feedback. *Reasoning:* =E2=80=A2 A proposal for a new package can be submitted from bot accounts, but the PR should be tagged with a human contact so the opam-repo maintainers know who to talk to. =E2=80=A2 Subsequent discussions regarding the PR should avoid excessive noise, such as large LLM-generated responses or automated triage logs, to avoid overloading the maintainers. =E2=80=A2 Any machine generated comments on a package publication PR must be explicitly identified as such. =E2=80=A2 When human reviewers ask questions or provide guidance, they must be met with human replies. The motivation here is twofold: we have a small but growing number of submissions from projects that have bot-based release procedures. In several cases, this means we've had to dig out who the responsible person actually is. And of course, there's more and more LLM spam out there waiting to spring on our poor human faces, but the submissions PRs have so far been largely considerate. Let's keep that going! Feedback welcome as always and the [PR discussion here] for those interested, and keep those opam package submissions coming :-) [opam-repository contribution guidance] [PR discussion here] Cohttp 6.3.0 released (OSEC-2026-16) =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=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: Anil Madhavapeddy 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 Dear all, cohttp 6.3.0 is released onto opam-repository with some important security fixes ([OSEC-2026-16]): =E2=80=A2 cohttp: `Cohttp.Path.resolve_local_file' no longer escapes the docroot when given percent-encoded traversal sequences such as `..%2f..%2f'. The URI path is percent-decoded exactly once before `.' and `..' segments are removed. (#1145 @avsm and Sapphire Livingstone, review by @mdales @edwintorok @patricoferris) =E2=80=A2 cohttp: `Cohttp.Path.resolve_local_file' collapses empty path segments and drops a trailing slash. A request for `/dir//sub/' now resolves to `docroot/dir/sub' instead of `docroot/dir//sub/'. (#1145 @avsm) =E2=80=A2 cohttp: Add `Cohttp.Path.normalise', which converts a request U= RI into a relative path that cannot ascend above its root. Servers that make access control decisions on path segments must apply it to `Request.uri' before inspecting them, as `Request.uri' does not normalise absolute-form or percent-encoded targets. (#1145 @avsm) =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 let callback _conn req _body =3D =E2=94=82 let uri =3D Cohttp.Request.uri req in =E2=94=82 match String.split_on_char '/' (Cohttp.Path.normalise uri) = with =E2=94=82 | "admin" :: _ when not (authorised req) -> Server.respond_= not_found () =E2=94=82 | _ -> =E2=94=82 let fname =3D Cohttp.Path.resolve_local_file ~docroot ~= uri in =E2=94=82 Server.respond_file ~fname () =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Normalisation is not applied by default, as existing code may depend on the present semantics, which are safe when not combined with local file resolution. =E2=80=A2 cohttp-mirage: The static file server normalises the request pa= th of every request, including directory requests, before looking it up in the mirage-kv store. Keys are now percent-decoded, so `/my%20file.txt' retrieves the key `my file.txt' rather than `my%20file.txt' (#1145 @avsm, review by @mdales @edwintorok) =E2=80=A2 cohttp-mirage: The `request_fn' callback receives the request U= RI unchanged. A request that falls back to an index page previously received a URI rewritten to that page. (#1145 @avsm) =E2=80=A2 cohttp: do not add `Transfer-Encoding~/~Content-Length' framing headers to responses that cannot have a body (1xx, 204 and 304). This fixes WebSocket handshakes. (@mefyl @avsm, #1141) =E2=80=A2 http: add `Status.body_allowed', the response-status counterpar= t to the existing `Method.body_allowed', for users constructing responses by hand (#1141) Please upgrade as soon as possible, and note the new `normalise' function for your own HTTP path splitting needs. Thank you to everyone who helped with handling the security issue, and especially Sapphire Livingstone for the discovery, report and guidance with the fix: =E2=80=A2 Sapphire Livingstone - REPORTER =E2=80=A2 Sapphire Livingstone - REMEDIATION_DEVELOPER =E2=80=A2 Anil Madhavapeddy - REMEDIATION_DEVELOPER =E2=80=A2 Anil Madhavapeddy - REMEDIATION_REVIEWER =E2=80=A2 Michael Dales - REMEDIATION_REVIEWER =E2=80=A2 Edwin Torok - REMEDIATION_REVIEWER =E2=80=A2 Patrick Ferris - REMEDIATION_REVIEWER =E2=80=A2 Hannes Mehnert - COORDINATOR [OSEC-2026-16] 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 everyone, We are happy to announce the release of opam 2.6.0~beta1. This version is a beta, we invite users to test it to spot previously unnoticed bugs as we head towards the stable release. Main changes compared to 2.6.0~alpha1 =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=80=A2 :recycling_symbol: `opam init --reinit' (command typically call= ed after upgrading from an older opam version) got improved. It now stops asking to retry the command when upgrading from a 2.1 opam root, and regenerates switches metadata to allow tools that use the opam library to load the switch informations without modifying the opam root ([#7057], [#7066]) =E2=80=A2 :houses: When `--safe' is given, opam used to reset debug-level= to 0. This is no longer the case. Consider updating your scripts accordingly. ([#7000]) =E2=80=A2 :shuffle_tracks_button: opam now disable git gc/maintenance on repositories it maintains. This is because git spawns maintenance tasks in the background which creates/removes/modifies files and unaware opam processes can sometimes break on a race-condition when handling such a git repository ([#7031]) :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]. [#7057] [#7066] [#7000] [#7031] [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~beta1" =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~beta1" =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] Jane Street Libraries (base/core/async/etc) with 5.5 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=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: Stefan Muenzel 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 (Note: much of the linked repos are modified with the the help of LLMs, so please do check the diff to the upstream version before installing. Most diffs are very small. Also, this release is not affiliated with Jane Street) Since the current version of the Jane Street public release libraries are targeting either older version of the compiler, or OxCaml, I've made a version of the jane street opam repository that targets 5.5. Almost all ~300 libraries are available (or at least build), with the exception of some heavy oxcaml users, such as skyline. Versions available are v0.18_preview.130.100+614 and v0.18_preview.130.106+341. The opam repository is available at , and the repo used to generate this is at Note that you need ppxlib > 0.38.0, due to I believe things should mostly work, but please do comment about any issues that you have. OCaml running on a 1960s UNIVAC 1219B =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=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: Nathan Farlow 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've been meaning to post a recent-ish project of mine where I ran OCaml (and much more) on a 1960s UNIVAC 1219B! The demo I chose to run was a sudoku solver. In short, this was done by compiling OCaml to C, C to RISC-V, and then emulating RISC-V on the UNIVAC. Full UNIVAC toolchain: [Writeup], and [source]. Please see the my comment below for the other links! I'm unable to post more than two links in a post. I also ran an OCaml program submitted by a friend that computed factors of numbers. At one point we thought the program crashed, but we were delighted when the program resumed ~5 minutes later. Turns out garbage collecting is slow on this machine :slight_smile: Oh, and it works with OxCaml too! Enjoy! Below are some pictures. (Disregard the earlier output, that was a run of ELIZA :slight_smile:) /Editor note: I=E2=80=99m inlining the links that were in the subsequent messages./ OCaml to C:[ Writeup], and[ source] Sudoku solver source:[ OCaml], and[ compiled to C] [Writeup] [source] [ Writeup] [ source] [ OCaml] [ compiled to C] 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 August 18 to 25, 2026.

OSEC-2026-16: cohttp: path traversal

Hannes Mehnert announced

Dear everyone,

we just published a security advisory for cohttp - please find it below=20 (and as usual at h= ttps://github.com/ocaml/security-advisories and=20 https://osv.dev/= list?q=3D&ecosystem=3Dopam)

Best,

Hannes 

id: OSEC-2026-16
modified: "2026-08-20T18:15:00Z"
published: "2026-08-20T18:15:00Z"
severity: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"
severity_score: "7.5 (High)"
affected: "cohttp" {< "6.3.0"}
events: [
   [
     git "https://github.com/mirage/ocaml-cohttp.git" [
       [fixed "5f5a65ec3289c1cd8072bdf0ef22c181b4f11356"]
     ]
   ]
]
credits: [
   [reporter "Sapphire Livingstone"]
   [remediation_developer "Sapphire Livingstone"]
   [remediation_developer "Anil Madhavapeddy"]
   [remediation_reviewer "Anil Madhavapeddy"]
   [remediation_reviewer "Michael Dales"]
   [remediation_reviewer "Edwin Torok"]
   [remediation_reviewer "Patrick Ferris"]
   [coordinator "Hannes Mehnert"]
]
cwe: [ CWE-22 ]
affected_bindings: [
   "Cohttp.Path.resolve_local_file"
   "Cohttp_async.Server.resolve_local_file"
   "Cohttp_lwt_unix.Server.resolve_file"
   "Cohttp_lwt.Make().resolve_local_file"
]

Path traversal in Cohttp.Path.resolve_local_file

The issue is that the function normalizes the URI path before percent decoding it: 

let resolve_local_file ~docroot ~uri =3D

   let path =3D Uri.(pct_decode (path (resolve "http" (of_string "/")=20
uri))) in

   ...

Because %2f is decoded after Uri.resolve, encoded separators s= urvive dot-segment normalization. For example, a request path like: 

/static/..%2f..%2f..%2fetc/passwd

is normalized as a single encoded segment, then decoded into: 

/static/../../../etc/passwd

afterwards.

Timeline

YAMLx 0.5.0 + odds things about the project

Archive: https://discuss.ocaml.org/t/ann-yamlx-0-5-0-odd= s-things-about-the-project/18465/1

Martin Jambon announced

I just released YAMLx 0.5.= 0 (release notes)= which provides a few fixes and improvements since the origina= l announcement in April. YAMLx is a pure-OCaml library implementing the= complex YAML 1.1 and 1.2 specifications. It aims to provide a complete yet= convenient user interface to manipulate data in this popular format.

Beyond the boring announcement, this is an opportunity for me to bring your= attention (again?) to the unusual aspects of the YAMLx project. It is sacr= ilegious and experimental along 3 main axes:

AI use

  • Most of the implementation is AI-generated (~10K lines).
  • The interfaces are mostly human-crafted (~800 lines).

Authorship model

  • The project has only one single traditional contributor.
  • Contributions are encouraged in the form of bug reports and detailed fe= ature requests.
  • The project doesn't take external code contributions.

Funding

  • The library is available for free under a strong copyleft license (AGPL= ).
  • A one-time contribution ($500) gets your organization a perpetual comme= rcial license.
  • Past the funding threshold ($5,000), everyone will get a permissive lic= ense for free (ISC).

— I'm happy to go over the motivations for these choices. Just ask.

Opam repository package contributors should have a human behin= d them

Archive: https://discuss.ocaml.or= g/t/opam-repository-package-contributors-should-have-a-human-behind-them/18= 466/1

Anil Madhavapeddy announced

Dear all,

I wanted to draw your attention to a new bit of opam-repository contributio= n guidance that we have just included.

14. Package contributors accounts should have a human behind t= hem The review work by the maintainers of opam-repository is carri= ed out by humans, and we need to have a contact to respond to our feedback.

Reasoning:

  • A proposal for a new package can be submitted from bot accounts, but th= e PR should be tagged with a human contact so the opam-repo maintainers kno= w who to talk to.
  • Subsequent discussions regarding the PR should avoid excessive noise, s= uch as large LLM-generated responses or automated triage logs, to avoid ove= rloading the maintainers.
  • Any machine generated comments on a package publication PR must be expl= icitly identified as such.
  • When human reviewers ask questions or provide guidance, they must be me= t with human replies.

The motivation here is twofold: we have a small but growing number of submi= ssions from projects that have bot-based release procedures. In several cas= es, this means we've had to dig out who the responsible person actually is.

And of course, there's more and more LLM spam out there waiting to spring o= n our poor human faces, but the submissions PRs have so far been largely co= nsiderate. Let's keep that going! Feedback welcome as always and the PR discussion her= e for those interested, and keep those opam package submissions coming = :-)

Cohttp 6.3.0 released (OSEC-2026-16)

Archive: https://discuss.ocaml.org/t/cohttp-6-3-0-released-osec-202= 6-16/18467/1

Anil Madhavapeddy announced

Dear all,

cohttp 6.3.0 is released onto opam-repository with some important security = fixes (OSEC-2026-16):

  • cohttp: Cohttp.Path.resolve_local_file no longer escapes t= he docroot when given percent-encoded traversal sequences such as ..%2f..%2f. = The URI path is percent-decoded exactly once before . and .. s= egments are removed. (#1145 @avsm and Sapphire Livingstone, review by @mdales @edwintorok @patri= coferris)
  • cohttp: Cohttp.Path.resolve_local_file collapses empty pat= h segments and drops a trailing slash. A request for /dir//sub/ now resolves = to docroot/dir/sub instead of docroot/dir//sub/. (#1= 145 @avsm)

  • cohttp: Add Cohttp.Path.normalise, which converts a request UR= I into a relative path that cannot ascend above its root. Servers that make access control decisions on path segments must apply it to Request.uri before inspecting them, as Request.uri does not normalise absolute-fo= rm or percent-encoded targets. (#1145 @avsm) 

    let callback _conn req=
 _body =3D
  let uri =3D Cohttp.Request.uri req in
  match String.split_on_char '/' (Cohttp.Path.normalise uri) with
  | "admin" :: _ when=
 not (authorised req) -> <=
span style=3D"color: #557400; font-weight: bold;">Server.respond_not=
_found ()
  | _ ->
      let fname =3D Cohttp.Path.resolve_local_file ~docroot ~uri in
      Server.resp=
ond_file ~fname ()

    Normalisation is not applied by default, as existing code may depend on the present semantics, which are safe when not combined with local file resolution.

  • cohttp-mirage: The static file server normalises the request path of ev= ery request, including directory requests, before looking it up in the mirage-kv store. Keys are now percent-decoded, so /my%20file.txt retriev= es the key my file.txt rather than my%20file.txt (#1145 @avs= m, review by @mdales @edwintorok)
  • cohttp-mirage: The request_fn callback receives the reques= t URI unchanged. A request that falls back to an index page previously received a URI rewritten to that page. (#1145 @avsm)
  • cohttp: do not add Transfer-Encoding~/~Content-Length fram= ing headers to responses that cannot have a body (1xx, 204 and 304). This fixes WebSocket handshakes. (@mefyl @avsm, #1141)
  • http: add Status.body_allowed, the response-status counter= part to the existing Method.body_allowed, for users constructing responses= by hand (#1141)

Please upgrade as soon as possible, and note the new normalise= function for your own HTTP path splitting needs.=20

Thank you to everyone who helped with handling the security issue, and espe= cially Sapphire Livingstone for the discovery, report and guidance with the= fix:

  • Sapphire Livingstone - REPORTER
  • Sapphire Livingstone - REMEDIATION_DEVELOPER
  • Anil Madhavapeddy - REMEDIATION_DEVELOPER
  • Anil Madhavapeddy - REMEDIATION_REVIEWER
  • Michael Dales - REMEDIATION_REVIEWER
  • Edwin Torok - REMEDIATION_REVIEWER
  • Patrick Ferris - REMEDIATION_REVIEWER
  • Hannes Mehnert - COORDINATOR

opam 2.6.0~alpha1

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

Continuing this thread, Kate announced

Hi everyone,

We are happy to announce the release of opam 2.6.0~beta1.

This version is a beta, we invite users to test it to spot previously unnot= iced bugs as we head towards the stable release.

Main changes compared to 2.6.0~alpha1

  • :recycling_symbol: opam init --reinit (command typically c= alled after upgrading from an older opam version) got improved. It now stop= s asking to retry the command when upgrading from a 2.1 opam root, and rege= nerates switches metadata to allow tools that use the opam library to load = the switch informations without modifying the opam root (#7057, #7066)
  • :houses: When --safe is given, opam used to reset debug-le= vel to 0. This is no longer the case. Consider updating your scripts accord= ingly. (#7000)
  • :shuffle_tracks_button: opam now disable git gc/maintenance on reposito= ries it maintains. This is because git spawns maintenance tasks in the back= ground which creates/removes/modifies files and unaware opam processes can = sometimes break on a race-condition when handling such a git repository (#7031)

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

Jane Street Libraries (base/core/async/etc) with 5.5

Archive: https://discuss.ocaml.org/t/jane-street-li= braries-base-core-async-etc-with-5-5/18469/1

Stefan Muenzel announced

(Note: much of the linked repos are modified with the the help of LLMs, so = please do check the diff to the upstream version before installing. Most di= ffs are very small. Also, this release is not affiliated with Jane Street)

Since the current version of the Jane Street public release libraries are t= argeting either older version of the compiler, or OxCaml, I've made a versi= on of the jane street opam repository that targets 5.5.

Almost all ~300 libraries are available (or at least build), with the excep= tion of some heavy oxcaml users, such as skyline. Versions available are v0= .18_preview.130.100+614 and v0.18_preview.130.106+341.

The opam repository is available at https://github.com/public-release-reloaded/= opam-repository, and the repo used to generate this is at https://github.com/public-release-reloaded-engineering/public-release-re= loaded

Note that you need ppxlib > 0.38.0, due to https://github.com/ocaml-ppx/ppxlib/pull/644

I believe things should mostly work, but please do comment about any issues= that you have.

OCaml running on a 1960s UNIVAC 1219B

Archive: https://discuss.ocaml.org/t/ocaml-running-on-a-1960s-un= ivac-1219b/18470/1

Nathan Farlow announced

Hi!

I've been meaning to post a recent-ish project of mine where I ran OCaml (a= nd much more) on a 1960s UNIVAC 1219B! The demo I chose to run was a sudoku= solver. In short, this was done by compiling OCaml to C, C to RISC-V, and = then emulating RISC-V on the UNIVAC.

Full UNIVAC toolchain: Writeup, and source. Please= see the my comment below for the other links! I'm unable to post more than= two links in a post.

I also ran an OCaml program submitted by a friend that computed factors of = numbers. At one point we thought the program crashed, but we were delighted= when the program resumed ~5 minutes later. Turns out garbage collecting is= slow on this machine :slight_smile:

Oh, and it works with OxCaml too!

Enjoy! Below are some pictures. (Disregard the earlier output, that was a r= un of ELIZA :slight_smile:)

3D"f77=

3D"57=

Editor note: I=E2=80=99m inlining the links that were in the subsequent = messages.

OCaml to C: W= riteup, and sour= ce

Sudoku solver source: OCaml, and compi= led to C

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/BsSVW56ZmGBA0KO07S5ccFAmqNRgAbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzHxxhbGFuLnNjaG1pdHRAcG9seXRlY2huaXF1ZS5v cmcACgkQBA0KO07S5cfi2Af/WOmmHyUjma5XaAzT+DEaZGxue43vdCoAyehkt50P GpEcuIuEunQ26WP62+nF5vznPB58yW/OLK+uGQX0LFVRJbLXjK6WJj+XpK5vmHRt 5xcZXdMLy5SCZcw6j8k5vCT+wm8g5MbRpSRsWa20o51reLVjIe08PfmPvjRl4Bqo Gva62C7ZPHIa8SxIedcUOJBwYwy8GRlxSwYmSky1I40jdBnOffDbO9+3AhQo7uWt zx/YcO4rZAdmG6RUXcxvdjzBHiLI+Q1A5p+RCIgr6bL1WZF5q4sW12V3DyQ1HzH3 JQ+h4swvoqThTq9UQrLLVABFS4NlpBjrFuYrMW/EYHaeOQ== =1rHc -----END PGP SIGNATURE----- --===-=-=--