fidzu : debian

On Friday May the 13th OpenSSL project has published advisory details for CVE-2026-2673. The CVE is treated as non-important by the project. The patches are only provided as commits on the stable branches. No git tag, no precise fixed version, and no source tarballs provided.

The patches that were merged to openssl-3.5 and openssl-3.6 branches were not based on top of the last stable point release and did not split code changes & documentation updates. It means that cherry-picking the commits referenced in the advisory will always lead to conflicts requiring manual resolution. It is not clear if support is provided for snapshot builds off the openssl-3.5 and openssl-3.6 branches. As the builds from the stable branches declare themselves as dev builds of the next unreleased point release. For example, in contrast to projects such as vim and glibc, with every commit to stable branches explicitly recommended for distributors to ship and is supported.

I have requested OpenSSL upstream in the past for the security fixes to branch off the last point release, commit code changes separate from the NEWS.md / CHANGES.md updates, and then merge that into the stable branches. This way the advisory that recommends cherry-picking individual commits, would actually apply conflict free - at no additional maintenance burden to the OpenSSL project and everyone who has to cherry-pick these updates. There is a wide support voiced for such strategy by the OpenSSL distributors and the OpenSSL Corporation. But this is not something that OpenSSL Project is yet choosing to provide.

To avoid duplication of work, I am starting to provide stable OpenSSL re-releases of the last upstream tagged stable point release with security only patches split into code-change only; documentation update; version update to create security only source tarball releases that are easy to build; easy to identify by the security scanners; and which cherry-pick changes without conflicts. The first two releases are published on GitHub as immutable releases with attestations:

• OpenSSL 3.6.1+1 - OpenSSL 3.6.1 with fix for CVE-2026-2673
• OpenSSL 3.5.5+1 - OpenSSL 3.5.5 with fix for CVE-2026-2673

16 Mar 2026 2:11am GMT

On our way to Austria last week, on March 6th, we left my daughter's laptop on a train: ICE 1201 (Hamburg-Harburg to Bludenz).

The laptop is a Lenovo X230. The most obvious distinguishing feature is a pink Mathilda Hands sticker in the middle of the lid.

I seem to remember that it also has some hexagonal stickers, one probably being one of these:

The keyboard layout is British (with a £ above the 3).

It was left in coach 24 of ICE 1201, next to seats 51-54, in the luggage gap between the seats, on the floor.

My hope is that whoever found it will end up searching for Mathilda Hands and see this. If that's how you got here, please email me: phil-lostlaptop2026@hands.com - doing so will make Mathilda (and me) most cheerful.

15 Mar 2026 10:04pm GMT

A maintenance release 0.9.14 of the RcppClassic package arrived earlier today on CRAN, and has been built for r2u. This package provides a maintained version of the otherwise deprecated initial Rcpp API which no new projects should use as the normal and current Rcpp API is so much better.

A few changes had cumulated up since the last release in late 2022. We updated continuous integration scripts a few times, switched to Authors@R in DESCRIPTION, and rejigged build scripts a little to accommodate both possible build architectures for macOS. We also updated the vignette by updating all reference and switching the new asis vignette builder now available in Rcpp.

CRANberries also reports the changes relative to the previous release from 3 1/2 years ago. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

15 Mar 2026 8:25pm GMT