fidzu : debian

I just read this informative article on ANSI terminal security [1]. The author has written a tool named vt-houdini for testing for these issues [2]. They used to host an instance on their server but appear to have stopped it. When you run that tool you can ssh to the system in question and without needing a password you are connected and the server probes your terminal emulator for vulnerabilities. The versions of Kitty and Konsole in Debian/Trixie have just passed those tests on my system.

This will always be a potential security problem due to the purpose of a terminal emulator. A terminal emulator will often display untrusted data and often data which is known to come from hostile sources (EG logs of attempted attacks). So what could be done in this regard?

Memory Protection

Due to the complexity of terminal emulation there is the possibility of buffer overflows and other memory management issues that could be used to compromise the emulator.

The Fil-C compiler is an interesting project [3], it compiles existing C/C++ code with memory checks. It is reported to have no noticeable impact on the performance of the bash shell which sounds like a useful option to address some of these issues as shell security issues are connected to terminal security issues. The performance impact on a terminal emulator would be likely to be more noticeable. Also note that Fil-C compilation apparently requires compiling all libraries with it, this isn't a problem for bash as the only libraries it uses nowadays are libtinfo and libc. The kitty terminal emulator doesn't have many libraries but libpython is one of them, it's an essential part of Kitty and it is a complex library to compile in a different way. Konsole has about 160 libraries and it isn't plausible to recompile so many libraries at this time.

Choosing a terminal emulator that has a simpler design might help in this regard. Emulators that call libraries for 3D effects etc and native support for displaying in-line graphics have a much greater attack surface.

Access Control

A terminal emulator could be run in a container to prevent it from doing any damage if it is compromised. But the terminal emulator will have full control over the shell it runs and if the shell has access needed to allow commands like scp/rsync to do what is expected of them then that means that no useful level of containment is possible.

It would be possible to run a terminal emulator in a container for the purpose of connecting to an insecure or hostile system and not allow scp/rsync to/from any directory other than /tmp (or other directories to use for sharing files). You could run "exec ssh $SERVER" so the terminal emulator session ends when the ssh connection ends.

Conclusion

There aren't good solutions to the problems of terminal emulation security. But testing every terminal emulator with vt-houdini and fuzzing the popular ones would be a good start.

Qubes level isolation will help things in some situations, but if you need to connect to a server with privileged access to read log files containing potentially hostile data (which is a common sysadmin use case) then there aren't good options.

• [1] https://dgl.cx/2023/09/ansi-terminal-security
• [2] https://github.com/dgl/vt-houdini
• [3] https://lwn.net/Articles/1042938/

11 Jan 2026 3:46am GMT

Team Rcpp is thrilled to share that an exciting new version 1.1.1 of Rcpp is now on CRAN (and also uploaded to Debian and already built for r2u).

Having switchted to C++11 as the minimum standard in the previous 1.1.0 release, this version takes full advantage of it and removes a lot of conditional code catering to older standards that no longer need to be supported. Consequently, the source tarball shrinks by 39% from 3.11 mb to 1.88 mb. That is a big deal. (Size peaked with Rcpp 1.0.12 two years ago at 3.43 mb; relative to its size we are down 45% !!) Removing unused code also makes maintenance easier, and quickens both compilation and installation in general.

This release continues as usual with the six-months January-July cycle started with release 1.0.5 in July 2020. Interim snapshots are always available via the r-universe page and repo. We continue to strongly encourage the use of these development released and their testing-we tend to run our systems with them too.

Rcpp has long established itself as the most popular way of enhancing R with C or C++ code. Right now, 3020 packages on CRAN depend on Rcpp for making analytical code go faster and further. On CRAN, 13.1% of all packages depend (directly) on Rcpp, and 60.9% of all compiled packages do. From the cloud mirror of CRAN (which is but a subset of all CRAN downloads), Rcpp has been downloaded 109.8 million times. The two published papers (also included in the package as preprint vignettes) have, respectively, 2151 (JSS, 2011) and 405 (TAS, 2018) citations, while the the book (Springer useR!, 2013) has another 715.

This time, I am not attempting to summarize the different changes. The full list follows below and details all these changes, their respective PRs and, if applicable, issue tickets. Big thanks from all of us to all contributors!

Changes in Rcpp release version 1.1.1 (2026-01-08)

• Changes in Rcpp API:

  • An unused old R function for a compiler version check has been removed after checking no known package uses it (Dirk in #1395)

  • A narrowing warning is avoided via a cast (Dirk in #1398)

  • Demangling checks have been simplified (Iñaki in #1401 addressing #1400)

  • The treatment of signed zeros is now improved in the Sugar code (Iñaki in #1404)

  • Preparations for phasing out use of Rf_error have been made (Iñaki in #1407)

  • The long-deprecated function loadRcppModules() has been removed (Dirk in #1416 closing #1415)

  • Some non-API includes from R were refactored to accommodate R-devel changes (Iñaki in #1418 addressing #1417)

  • An accessor to Rf_rnbeta has been removed (Dirk in #1419 also addressing #1420)

  • Code accessing non-API Rf_findVarInFrame now uses R_getVarEx (Dirk in #1423 fixing #1421)

  • Code conditional on the R version now expects at least R 3.5.0; older code has been removed (Dirk in #1426 fixing #1425)

  • The non-API ATTRIB entry point to the R API is no longer used (Dirk in #1430 addressing #1429)

  • The unwind-protect mechanism is now used unconditionally (Dirk in #1437 closing #1436)

• Changes in Rcpp Attributes:

  • The OpenMP plugin has been generalized for different macOS compiler installations (Kevin in #1414)

• Changes in Rcpp Documentation:

  • Vignettes are now processed via a new "asis" processor adopted from R.rsp (Dirk in #1394 fixing #1393)

  • R is now cited via its DOI (Dirk)

  • A (very) stale help page has been removed (Dirk in #1428 fixing #1427)

  • The main README.md was updated emphasizing r-universe in favor of the local drat repos (Dirk in #1431)

• Changes in Rcpp Deployment:

  • A temporary change in R-devel concerning NA part in complex variables was accommodated, and then reverted (Dirk in #1399 fixing #1397)

  • The macOS CI runners now use macos-14 (Dirk in #1405)

  • A message is shown if R.h is included before Rcpp headers as this can lead to errors (Dirk in #1411 closing #1410)

  • Old helper functions use message() to signal they are not used, deprecation and removal to follow (Dirk in #1413 closing #1412)

  • Three tests were being silenced following #1413 (Dirk in #1422)

  • The heuristic whether to run all available tests was refined (Dirk in #1434 addressing #1433)

  • Coverage has been tweaked via additional #nocov tags (Dirk in #1435)

• Non-release Changes:

  • Two interim non-releases 1.1.0.8.1 and .2 were made in order to unblock CRAN due to changes in R-devel rather than Rcpp

Thanks to my CRANberries, you can also look at a diff to the previous interim release along with pre-releaseds 1.1.0.8, 1.1.0.8.1 and 1.1.0.8.2 that were needed because R-devel all of a sudden decided to move fast and break things. Not our doing.

Questions, comments etc should go to the GitHub discussion section list]rcppdevellist off the R-Forge page. Bugs reports are welcome at the GitHub issue tracker as well. Both sections can be searched as well.

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 sponsor me at GitHub.

10 Jan 2026 8:37pm GMT

Inspiration

In November I watched a short documentary about a guy who grew pearl oyster mushrooms in his backyard. They used pallet boxes (half of a europallet, 60x80x20 cm) as box to keep the substrate the mycelium feeds on in. Since I really enjoy (foraged) mushrooms and had the raw materials lying around, I opted to build it myself. This also had the benefit of using what was available and not just consuming, i.e. buying a pallet box.

Preparing the raw materials

I had 4.5 m x ~ 25 cm wooden spruce planks at home. My plan was to cut those into 2 m segments, then trim the edges down to 20 cm and then cut them into handy pieces, following the dimension of half a pallet box. This is what they looked after cutting them with an electric chainsaw to around 2 m:

You can see that the edges are still not straight, because that's how they came out of the sawmill.

Once that was done I visited a family member that had a crosscut saw, a table saw and a band saw; all that I would need. First we trimmed the edges of the 2m planks with the table saw so they were somewhat straight; then they were flipped and the other edge was cut straight, and their width cut down to 20 cm.

After moving them over to the crosscut saw dividing them into two 60 cm and one 80 cm was fairly easy. When cutting the 2m planks from the 4m ones I calculated with extra offcuts, so I got little waste overall and could use the whole length to get my desired board.

This is what the cut pieces looked like:

Assembly

I packed up my planks, now nicely cut to size, and I went to a hardware shop and bought hinges and screws. Assembly was fairly easy and fast: screw a hinge to a corner, hold the other plank onto the hinge so that the corners of both boards touch, and affix the hinge.

When this was done, the frame looked like this:

As last step I drilled 10mm holes more or less random in the middle of the box. This is where the mushrooms will grow out of later and can be harvested.

Closing thoughts

This was a fun project I finished in a day. The hinges have the benefit that they allow the box to be folded up lenght-wise: This allows for convenient storage. Since it's too cold outside right now, cultivation will have to wait until spring. This also just needs mycelium one can just buy, and some material fungus digests. They can also be fed coffee grounds, and harvest of the fruit body is possible circa every two weeks.

10 Jan 2026 5:45pm GMT