Notices by Simon Josefsson (jas@fosstodon.org)

Please welcome Guile Hoot in Debian #guile https://tracker.debian.org/pkg/guile-hoot

@cwebber Doesn’t MNT devices require a non-free blob to train DDR memory, and to even start at all? Which to me is worse than optional WiFi or GPU blobs. The state of libre-friendly user controllable hardware is sad. The MNT effort is great, and helps, but for me this became a deal-breaker to rely more on my MNT Reform.

@lxo Would "compiling", for example, the binary proprietary Intel WiFi firmware blobs from a text-file into a binary magically make things acceptable if the license on the text file is BSD-3-Clause?

@lxo I assumed SOF contained more than just the source-code for the firmware here, but that may be incorrect. What you write seems consistent with the documentation I'm reading. The "source code" for the ALSA topology is also interesting, as it is compiled into a binary /lib/firmware/ blob. There is source code for it, but it is so hardware-specific and magical that I wonder if it would qualify as the preferred form of making modifications to. https://github.com/alsa-project/alsa-topology-conf/blob/master/topology/hda-dsp/skl_hda_dsp_generic-tplg.conf

@dalias ALL of telnetd is fundamentally broken and should be considered deprecated! We just keep the dead on life support treatment here.

@dalias Granted, it would be possible to re-implement all of this to properly handle USER being a string like '-f root' and pass it on to login(1) as one parameter and let login(1) deal with invalid usernames. But is there a real use-case for anything like that? We'll see if the patch breaks someones deployment, it has potential for doing so

@lxo @Suiseiseki@freesoftwareextremist.com I’m no expert on SOF but I’m not sure this is a pure tivoization example? The SOF project contains a lot of FOSS code. But according to that documentation, it all requires a non-free signed firmware to be loaded. I’m not sure the source code for that firmware is public at all? But it doesn’t seem unlikely that (at least some parts of) SOF is still useful even if you don’t load that firmware.

@dalias Sure, but for a degenerate case of strings without SPC these are identical, no? The problem is the 'telnetd -E' parameter is documented to be template string, and there is no support for shell word lists at all. https://www.gnu.org/software/inetutils/manual/inetutils.html#Crafting-an-execution-string_002e

@dalias Sanitizing away SPC from inputs is one way to resolve word splitting. Arguably little of this code is elegant.

Enjoy this remote root exploit in telnetd! #telnet #gnu https://lists.gnu.org/archive/html/bug-inetutils/2026-01/msg00004.html

TIL that the LinuxFoundation "Open source audio DSP firmware and development tools" project assumes signed proprietary firmware verified by Intel ME in your CPU. So much for "Open Source". https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html#base-firmware

Guix on Trisquel & Ubuntu for Reproducible CI/CD Artifacts #guix #trisquel #Containers #podman https://blog.josefsson.org/2025/12/03/guix-on-trisquel-ubuntu-for-reproducible-ci-cd-artifacts/

@janneke Yes but achieving anything similar from within Debian seems hard to imagine, or? To me it seems simpler to explore building a smaller set of Debian packages directly from Guix binaries, which are then used to build the rest of the Debian archive, in the hopes that this incremental build process will ultimately be identical to a idempotent rebuild of Debian using itself.

On Binary Distribution Rebuilds https://blog.josefsson.org/2025/03/31/on-binary-distribution-rebuilds/

@vagrantc @josch Great work! I am still waiting for my Rk3588 order, but will try your Linux-libre-based kernel when I receive it. Can it boot to Guix? Did you notice any non-free stuff in those patches?

GNU InetUtils 2.6 release, with "git archive" tarball, GnuPG and Sigsum signatures, and reproducible tarballs including software build of material list nailed down to the particular Guix commit with tools used to generate the tarballs in GitLab pipeline. Happy supply-chain security Friday! https://lists.gnu.org/archive/html/bug-inetutils/2025-02/msg00002.html

@civodul @Mehrad The `podman load` barely takes any time at all, but indeed I want to use skopeo or podman from a native Guix config. I'm getting errors though, ideas? Maybe just a mkdir... https://gitlab.com/debdistutils/guix/container/-/jobs/8714694003

@Mehrad @civodul Latest successful container build is done here: https://gitlab.com/debdistutils/guix/container/-/jobs/8679061592

@Mehrad @civodul Building a Debian+Guix image takes around 25 minutes on a large GitLab runner node. Building the pure Guix image takes around 6 minutes, also on a large GitLab runner node. The Debian+Guix image is used to prepare the native Guix-only image. I have not yet tried to build another Guix-only image from the Guix-only image I have prepared, that is issue #1 and I think it is trivial. https://gitlab.com/debdistutils/guix/container/-/issues/1

OpenSSH and Git on a Post-Quantum SPHINCS+ #pq #ssh #sphincs+ https://blog.josefsson.org/2024/12/23/openssh-and-git-on-a-post-quantum-sphincs/