Logbook

git security fixes lead to "fatal: transport 'file' not allowed" error in CI systems; CVE-2022-39253

If you are running a CI system that uses git to check out software for builds, and if that environment uses "git submodule add" to bring in files from the filesystem, then you might be affected by this change.

As of git v2.38.1 and the back port of the associated patch to v2.30.6, v2.31.5, v2.32.4, v2.33.5, v2.34.5, v2.35.5, v2.36.3, and v2.37.4, git will now refuse to clone repositories via the --local clone optimization if there are symbolic links present within the objects directory. The vulnerability, CVE-2022-39253, describes an attack that traverses symbolic links to break a security boundary. Cory Snider of Mirantis gets credit for identifying this issue.

https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253 https://lore.kernel.org/lkml/[email protected]/

The Github security issue GHSA-3wp6-j8xr-qw85 provides a few more details, noting that the malicious actor can use this misfeature to attack "docker build" and "podman".

https://github.com/git/git/security/advisories/GHSA-3wp6-j8xr-qw85

The change in behavior is reported as bug 1993586 to Ubuntu's "Launchpad", and readers there have pinpointed the Ubuntu versions that have this change. The bug is closed as "invalid" as the change in behavior is as intended.

https://bugs.launchpad.net/ubuntu/+source/git/+bug/1993586

If your build is broken as a result of this change - noted by Jérôme Petazzoni to affect at least some Arch AUR packages and Debian apt packages - you will need to make changes. Here are some examples.

https://twitter.com/jpetazzo/status/1583112279012257797

Microsoft fixed their "go-infra" repository by adding the option -c protocol.file.allow=always to their git invocation in their test infra.

https://github.com/microsoft/go-infra/pull/71/files

The stack project of Haskell set a global variable with git config --global protocol.file.allow always in their integration test system. The "spack" package manager did likewise.

https://github.com/commercialhaskell/stack/pull/5909/files https://github.com/spack/spack/pull/33429

As of this writing, this Github search for the error string has 13 open issues, so there's some set of people who are chasing this down right now to get their build systems back online.

https://github.com/search?q=%22fatal%3A+transport+%27file%27+not+allowed%22&type=issues

SHEFA-2 cuts take the Shetland Islands offline

Two separate fiber cuts on the SHEFA-2 cable that connects the Faroe Islands to Scotland via the Shetland Islands took most of communications on the islands offline on 20 October 2022. Services were restored the next day, per a BBC report.

https://www.bbc.com/news/uk-scotland-north-east-orkney-shetland-63337473

SHEFA-2 ("SHEtland-FAroes") is run by SHEFA, a 100% owned subsidiary of Faroese Telecom. SHEFA-2 was put into service in 2008, replacing an earlier SHEFA-1 which dated from 1971.

https://www.shefa.fo

SubmarineCableMap.com has a detailed map, listing landing points at Maywick and Sandwick.

https://www.submarinecablemap.com/submarine-cable/shefa-2

BBC Radio Shetland is the broadcaster to the archipelago, and its evening broadcast of the 20th of October has an account of the impact on the 23,000 residents there. Phone service, internet service, automatic teller machines, and access to emergency services were all affected.

https://www.mixcloud.com/BBCShetland/good-evening-shetland-thursday-20th-of-october-2022/

In the case of a single fiber cut, there is redundancy, in the sense that traffic from Shetland has an alternate return path via the Faroe and the FARICE-1 cable. But there are only two ways out, and if both of them are offline.

Subsea cables go out of service with some regularity. Fishing trawlers which tow nets at the very bottom of the ocean will snag a cable, and this is a suspected cause of the Shetland incident. Other natural causes for outages include earthquakes and the associated submarine landslides that can wreck service. Submarine Telecoms Forum tracks these outages, which have affected diverse cables such as PPC-1 (Papua New Guinea), IMEWE (Egypt), Greenland Connect (Greenland), SEAMEWE-5 (Pakistan), and APG (Vietnam) in the past few months.

https://subtelforum.com/category/cable-faults-maintenance/

A more sinister threat to subsea cables is deliberate damage by military interests. The UK government cut off Germany's submarine telegraph cables in 1914 during World War I, which forced German communications onto the worldwide British network where they could be more easily intercepted and decoded.

https://www.bbc.com/news/world-europe-42367551

Since then the cable network has vastly expanded, but the threat is still there. And while there's no indication that the Shetland incident on SHEFA-2 is anything other than a routine failure, policy makers have recently raised an alarm of recent Russian activity in mapping the cable network.

https://www.theguardian.com/uk-news/2022/jan/08/uk-military-chief-warns-of-russian-threat-to-vital-undersea-cables

Converting hot takes into a proper weblog

I wonder what my blog would look like if I took my hot Twitter takes and wrote 500 words on each rather than 280 characters.

(Yes, I still have a blog, a couple of them actually.)

The instant publication of a tweet is very appealing, with a quick hit of dopamine possible if you happen to get really lucky and write something that triggers a quick response. That's great, in the same way that a rat pressing a lever thinks that getting fed is great.

In the olden days of web rings and RSS feeds and Google scooping up all of the blog content it could find, posting to a blog felt a lot more "live". If you wrote about something that people were searching for right at that moment, there was an opportunity to do serious numbers. Those days are mostly gone, with changes to the world leaving blogs behind as the source of hot news.

The biggest advantage of the blog format over the tweet (aside from its absurd length) is that you have a lot more room to ponder an idea and a lot more space to link out to other people's takes on the same subject. The writing has some space to breathe, there's a lot more chances to edit, and the shelf life of the words is a lot longer.

Not many people read blogs though any more so they fail for general audience seeking. We're in the Newsletter Era, so I suppose the reasonable option is to somehow cajole people into signing up for everything you publish. Direct email does increase the chance that any given thing will be read. The downside I guess is that readers expect to write back! Suddenly your hot take is an extended conversation and maybe you were just chasing a passing interest rather than a deep thought to ponder.

One thing is for sure: when you write blog instead of a tweet, there's a whole lot more time spent typing your own ideas, and a lot less time hitting the refresh button hoping someone else somewhere in the world has said something interesting. I can get into that.

My next small, hackable computer - a Steam Deck?

For the longest time the Raspberry Pi has been my go to for a small, inexpensive, easy to buy and hackable computer. I have a few of them running, powering a DMR gateway and an ADS-B receiver. Software support is good, third party peripheral support is good, and lots of people have gone to some substantial efforts to get workable tools running on arm64.

However;

The Pi has gotten very hard to buy over the past year, with most of the production inventory diverted to industrial and OEM clients. There is good supply of the RP2040 microcontroller, and the Pi folks seem to have diverted their "here, have a cheap and cheerful device to learn from" to systems built around that chip. That's great, don't get me wrong, but not my focus of interest right now.

This brings me to the subject line. What if the next obvious target for a small and hackable computer is not a Pi, but instead is a game machine? The Steam Deck runs all the Steam games, but it's Linux based, and it's easy to drop into a Linux environment. There's a built in display and a built in battery and easy ways to connect to external devices. And the form factor - a "cyberdeck" and not a bare board - is appealing.

Yes, it costs more; way more, to be honest. As of this writing there's still a queue for ordering so it will take a little while to ship. One per customer, please, so you're not going to see insane clusters of these things.

Some interesting reading:

Putting Tailscale on the Steam Deck, from Tailscale's Xe Iaso. Some of the trickier bits of systemd work you need to do in order to get the Tailscale VPN software running on the Steam Deck. You'll learn about systemd-sysext, which uses an overlay filesystem (overlayfs) to install components "on top of" an underlying immutable filesystem.

Running KrakenSDR on the Steam Deck, RTL-SDR Blog. KrakenSDR is a multi-device coherent software defined radio, with applications like direction finding for radio signals ("fox hunting"). The blog notes that the Steam deck "is essentially a powerful handheld computer with s creen and good battery life, so it makes an excellent mobile SDR computing platform too." For this particular application you'd want an external battery pack to power the SDR.

Listening to HAM radio on my Steam Deck, /u/freeloz on Reddit. A demo with video of SDR reception using an AirSPY HF+, a loop antenna, and the Gqrx software.

Flathub is a home for "flatpaks", a portable software installation format supported natively on SteamOS. This lets you develop your own applications and package them for easy use on the platform, and also opens up a library of software from the Linux world that's easier to install.

Of course, the main market for the Steam Deck is games, either brand new titles or old games via emulation.

updates and later additions

Direction-finding with help from the Steam Deck, Hackaday, 2022. Aaron (cemaxecuter) demonstrates radio direction finding with KrakenSDR and a Steam Deck as a portable controller in marine operations on a boat on Lake Redwine in Georgia. Like and subscribe to his Youtube channel for more information about DragonOS Focal, a software distribution for SDR applications.

Asahi Linux on MacBook Air M1 - an update

Previously: Asahi Linux alpha on M1 MacBook Air / Apple Silicon, first impressions

After a few months of idleness, I decided to revisit my Asahi Linux installation on my MacBook Air. As you may remember, Asahi Linux is adapted for the Apple Silicon (M1 and M2) chips, and is based on Arch Linux. It installs in a partiton on your Mac and you can dual boot it (long press the power key at start to bring up a menu).

The first snag in getting online was logging in. I am sure that I picked an easy to remember yet secure password five months ago, so easy to remember and so secure that I didn't write it down. Oops. Couldn't remember it, the usual tries didn't work, so it was time to break in.

Fortunately, Arch Linux has a nice primer on resetting a lost root password which jogged my memory as to what was possible. When you edit the boot sequence so that the init process is replaced with a shell - e.g "init=/bin/sh" - it's straightforward to boot into a single-user mode and run "passwd" to fix up the situation. Make sure that the drive in question is mounted read-write, and make sure you "sync" a few times after doing the edits so that the buffers are flushed to disk.

That little problem disposed with, it was time to update the system. Arch uses the "pacman" package manager, and the command "pacman -Syu" is all you need to trigger a complete update. There were 800+ packages that had updates. To be extra sure that everything was all in sync after all of those changes, I did a reboot and the system came up just fine.

When last I tried this, the Chromium browser didn't work because it didn't support the 16K pages that Asahi (and the Mac hardware) provides. Since then that bug has been fixed and Chromium starts just fine, with the caveat that it throws a couple of GPU related complaints along the lines of "Exiting GPU process due to errors during initialization" when starting. This is Chromium 104.0.5112.101 installed with "pacman -S chromium". Chromium did work well enough that a little bit of web browsing worked ok, but I didn't try anything very complex (the usual show-stopper is Youtube).

I had previously installed Firefox and that seems to continue to be just fine.

One goal I have on this system is to get some Electron based apps up and running, notably Obsidian. Obsidian has an "Appimage" flavor of distribution for arm64, so I tried that, and it immediately crashed with a segmentation fault (16K pages again). I can't tell at a glance which version of Electron that Obsidian ships with, but with a similar discussion for VSCode the winning version seems to be some flavor of Electron 19. I did not pursue trying VSCode out, but the VSCode issue Update to Electron 19 looks like the cutting edge of discussion. I'll make a point to try to get that working next time I'm in.

Asahi doesn't start up out of the box with an ssh daemon installed, so I put opensshd on the system and enabled it. Together with Tailscale, this got me to the point where I successfully logged into Asahi from my Android phone. A next step will be to enable "Tailscale ssh" on Asahi, but I stopped before adding that step.

My usual observations about the Linux desktop user interface still hold - everything feels just a little bit less precise than the Mac desktop (or even the Windows desktop) that I am used to, and there are enough key bindings that I am also used to that are different enough to make things confusing for occasional use.

All in all a good evening's exercise, good to have a system in reserve for when you need to see how things are. I'm not ready though to have Asahi as a daily driver.

Obsidian as a daily note taker, a year out

I started using Obsidian about a year ago, and switched away from Github Issues about six months ago. So far so good. As is my habit, here's some notes on the process that will probably be more useful to me than they will be to you, but that's the nature of blogging these days to write notes to yourself mostly.

Obsidian has completely captured the "daily diary" part of my daily routine, as well as the "write down what you're going to do today before you do it", and the "take notes in wiki format". All of that is about 80% of what I need, and so it gets repeated daily use on my laptop.

Surprisingly, even though I can and do sync my laptop with my Android phone, I don't really use Obsidian much on my phone! To the extent that I do, it's for lookup rather than typing. I guess part of that is that the computer is so much faster as an input device that for any writing of any length I'd rather be at a full sized good keyboard.

When I gave up on Github Issues for daily tracking, there were 10000 issues that I had gone through, and I could tell you with some certainly how long various items had been on my todo list. And you know what, that's not a knowledge about myself that I miss having. I write things down and then I do them or don't do them. The process leaves enough of a trail that I can reconstruct my thoughts. I'm not really reporting out to anyone else the progress towards any one specific goal, so there's less unfinished business to worry about.

Is there unfinished business? Of course. It's just that's accepted as a normal course of events, and you get to things because you remember them and not because there's some Master List Of All Undone Tasks that you consult before taking on the next iteration of your day.

I love Obsidian as a daily note pad, and I really like it that I can bop around in about 1600 separate pages that are a fair capture of a year's worth of doing things and feel at least to a certain degree that it's a connected whole.

At 1600 pages a year, it's about six years when I hit the 10000 page mark. That would be a nice body of work, and by then some other system for writing will probably be available on some shiny new computer and I'll want to start over again from scratch. But until then - this is pretty nice, and I intend to keep at it. (Check back in 2027 and see if I still am thinking the same way.)

backup state - good, bad, ugly

Backups get worse over time, keep these in mind when designing your backup strategy.

Good backups cover your working set. If you accidentally clobber something you're currently working on, you can get it back with minimum fuss. A good backup also provides you with some protection against catastrophic drive loss or other wholesale catastrophe. Good backups generally have an ongoing monetary cost, so there's a risk that your backups will fail not because of hardware failure but because you missed a payment.

Bad backups can look like good backups until they fail to restore. Your bad backup would be a laptop backed up to a hard drive in the same house, both at risk of the same catastrophe like a fire. Bad backups are better than no backups if you're lucky, but you're not really doing this to be lucky.

Ugly backups are the worst. Imagine a decade old laptop which has had several attempts at file system organization. There are financial records mixed in with old photos mixed in with ancient versions of free software. You're not sure whether to throw the whole thing into the chipper, or to back it up very carefully. It will take too much time to sort through everything, much longer than it's worth. And yes while the drive is backed up carefully it's on old hardware that's expected to fail sooner rather than later.

Good backups consume time and money, but given enough money, there's not that much time needed to keep enough copies of your current working set of files active and alive. Once the working set grows - every photo you ever took, everything you ever downloaded, all those records of your existence - it gets harder. I don't have an easy answer for the "ugly" scenario except to do all you can to prevent it from happening, and a strong recommendation to sort through things up front rather than let random files clog up your drives.

For myself, the most important backup question: did I save enough pictures of my younger son as he was growing up? His older brother got all of the first photos on the first digital camera (backed up to floppy drives). Not so sure of the second child's digital record.

Also a sad reminder for those of us from the Napster era: we had very interesting digital music collections, and a lot of those digital files were "too big" at one point in the history of storage. Shiny new streaming services combined with ugly on-disk storage techniques means we just don't have that music as bits on disk anymore.

Learning complex systems, piecemeal - this time lima, limactl, Fedora and RISC-V

The pattern runs something like this.

1. Identify a shiny, new, and ferociously complex system that you'd like to know more about.

2. Bumble your way through the initial install, taking copious notes on things that will have changed by the next time you get around to look at them.

3. Declare victory after some trivial task beyond the initial install is complete.

This is an anti-pattern in a lot of ways. Perhaps the ferociously complex system can be safely ignored for a week or a year, rather than needing attention now. If it does merit attention, then give it a proper fully automated install rather than a haphazard try. Note that this might take a few uninstall cycles, that would be fine.

As an example, I have Rancher Desktop running on my MacBook Air M1. It seems to idle just fine, taking up a bunch of memory and a couple of cores but not getting in the way of actual use of the rest of the machine. I've installed exactly one application on it (my "sisyphus" function for OpenFaaS), and even that is less than ideal because the container it's running in isn't up to date. There's some complexity in there that I just barely remember about nerdctl.

And yet - and yet - here I go again with the same pattern. Gee, it would be interesting to have a Fedora version running Tailscale SSH on my M1 Mac. I'll bet I can run that under something - "lima" it is.

limactl start --name=fedora template://fedora

Try it out, run into something of course, a fresh issue at

https://github.com/tailscale/tailscale/issues/4908

in which Fedora Server at Fedora 36 doesn't want to run Tailscale SSH because of SELinux, but there's a workaround of sorts there. And with the workaround, I can ssh into an arm64 Fedora VM on my M1.

But wait, there's more. Armed with that knowledge, and looking at the limactl templates, I see there's a "riscv64" template that turns up a VM under emulation. A failed install later, notice that the Ubuntu distribution has moved a file, and we're up (and also have Tailscale SSH up again). Notes at

https://github.com/lima-vm/lima/issues/930

Now not just one but two different VMs running, plus a third in which to run Kubernetes. An embarrassment of riches (or perhaps just an embarrassment of idle cycles). Two more diverse systems for my tailnet, and two more chips away at a complex system to understand just a little bit better.

Adding Memory to a Zenith Z-151 with RDISK / From Info-IBMPC Digest v5n5

Date: Wed, 8 Jan 86 17:30:26 EST From: Edward_Vielmetti%[email protected] Subject: Adding Memory to a Zenith Z-151 with RDISK To: iph%[email protected]

I have the RDisk unit installed, and it works quite nicely. Available memory is 640K + a 640K ramdisk. I haven't experience any problems in the operation of it; installation was a bit tedious (pulling 45 chips, replacing them with 45 new 256K rams took about 3 hours).

Since then, I have heard (second hand) that Software Wizardry is offering a RamPal unit (the same type of setup) that gives 704K system memory and a 512K ramdisk. Don't know about prices for that unit, or availability or anything; if you're interested, check out SW ads in Sextant or another Heath/Zenith magazine.

For my purposes, I would rather have the maximum amount of system memory possible (with all the resident utilities I have, I only have 280K free !!!!!). There is a tradeoff involved.

Another thing--the RDisk is a little daughterboard, and it might be a tight fit if you have another card next to it. I ended up putting the memory card in next to an empty slot just to be safe.

Alternatives to the RDisk/RamPal scheme are to buy a card that implements the Extended Memory spec (Above Board, RAMPage! are some names). The memory that you add that way is useful for more than just ramdisks; Lotus v2, Symphony, Ready! and Framework all take advantage of the extended memory. The cost is another slot and several hundred dollars more for the card. RDisk is supposed to be compatible with EMS, if you want to go the whole hog.

For memory chips: Microprocessors Unlimited (check Byte ads) is excellent. Good prices, fast service (1-3 days!), intelligent people working there. If you want to order industrial-size quantities of memory chips (100+), I have had good results with D-L-C (check Electronic News ads). Service is on the order of a week to 10 days, and prices are better. (A minimum order may be necessary.)

Let me know what you decide to follow through with.

--Ed

Edward Vielmetti Computing Center Microgroup University of Michigan Ann Arbor, MI 48109

Asahi Linux alpha on M1 MacBook Air / Apple Silicon, first impressions

Some installation notes from getting Asahi Linux (alpha) running on an M1 MacBook Air (Apple Silicon).

Asahi Linux is a Linux distribution for Apple Silicon. The alpha installer release came out on 18 March 2022, and being brave, I decided to give it a try.

https://asahilinux.org/2022/03/asahi-linux-alpha-release/

Before you do the install, you need to upgrade your Apple Silicon machine to macOS Monterey 12.3 or better. MacRumors reports that if you have had your logic board replaced recently there are bricking issues with this release. My upgrade went smoothly, but if your MacBook has been in the shop recently you should take extra care.

https://www.macrumors.com/2022/03/17/macos-monterey-bricking-macs-logic-boards/

The install process itself went smoothly. In the course of doing it, the script will do a "live resize" of your existing MacOS partition to make room for a new partition that has Asahi Linux on it. The configuration supports a dual boot setup, so you can pick at boot time which OS you are running.

The installer downloads Asahi Linux, and if your network is not 1000% stable you might see this message

Error downloading data (<urlopen error [Errno 60] Operation timed out>), retrying

The progress indicator here is a series of +++ signs, as long as those continue to appear you'll be fine. If your network is not great it might take a long time, expect to download between 700MB and 4GB of data.

Follow the reboot instructions precisely after doing the install. "You need to fully shut down your machine, then boot by holding down the power button until you see “Entering startup options”, choose your new OS in the boot selector menu, and follow the prompts."

You'll boot into Asahi Linux, which is a derivative of Arch Linux ARM. There is an installer with a few options (pick your time zone, pick your keyboard layout, set an initial password) and you'll be into a desktop based on KDE Plasma. One of the things you'll pick is a system name; I chose a name distinct from but related to the main name of my MacBook to make it distinct.

https://archlinuxarm.org

If you haven't used Arch before, the package manager is "pacman", and there's a helpful "Rosetta" table which will help you figure out how to translate commands from other package managers into this one.

https://wiki.archlinux.org/title/Pacman/Rosetta

Plasma is a desktop environment from KDE, providing a familiar windows-icons-mouse environment. Coming from the Mac, you will notice that some keyboard bindings are different, for me notably this is cut/copy/paste which I always get confused in Linux systems. You may find Plasma familiar if you come from Kubuntu, which is a Ubuntu distro that uses Plasma instead of GNOME.

https://kde.org/plasma-desktop/

Firefox is a supported browser in Asahi Linux. What I noted was that the Retina display on my MacBook Air gave me teeny tiny text on the screen. You can bump up the magnification in the window to make the browser readable, but that's not quite enough to get the whole UI larger. Arch has a detailed article on "high DPI displays" (HiDPI) which specifies all of the various tweaks to the various applications that might be necessary to make the display just the way you like it.

https://wiki.archlinux.org/title/HiDPI

The first application I installed was Tailscale, a VPN that I use to connect my various and sundry systems together. The install went quickly using the Arch Linux instructions, even though those instructions promise only 64-bit x86 support.

https://tailscale.com

Feeling brave, the next thing I tried was getting Obsidian up and running. Obsidian is a personal notebook structured as a wiki based on Markdown. I keep lots and lots of notes in Obsidian, and if I'm going to use Asahi for any length of time I'll want to have it running. The options provided for Linux for arm64 are "Appimage", tar, and deb formats. Arch Linux ARM does not appear to have a prepackaged Obsidian ready to install, so I grabbed the tarball and gave it a try. The immediate error message was "segmentation fault".

https://obsidian.md

Obsidian is based on Electron and Chromium, and there are notes in the Asahi alpha distribution that Chromium is not supported due to its lack of support for 16K page sizes. Different aarch64 chips support different memory allocation configurations, with 4K pages being relatively universal and 64K pages originally found in RHEL and CentOS configurations. The M1 hardware supports 16K and 4K pages, and the Asahi team is starting with the 16K configuration for performance reasons as well as to shake out any remaining software bugs for the relatively few systems remaining that hard code a page size. The Chromium bug was first found by the Debian team as they were doing a port.

https://bugs.chromium.org/p/chromium/issues/detail?id=1301788

The identification of a PAGE_SIZE bug generally affecting aarch64 systems dates back at least as far as 2015, when the Go language was seen hard-coding a 64K page for that architecture. That bug in Go was fixed in 2016, after it was seen impacting the Docker overlay filesystem.

https://github.com/golang/go/issues/13191

The Asahi team has a short list of other software affected by the 16K page size issue, with status towards patches. The Chromium bug affects a whole set of Electron based applications. FEX, an x86 emulation library, is known to have issues that may be difficult to resolve in practice due to the deep-seated assumptions about the 4k page size in the x86 architecture. Emacs (good old Emacs) makes some assumptions about the page size being defined at compile time instead of at run time.

https://github.com/AsahiLinux/docs/wiki/Software-known-to-have-issues-with-16k-page-size

Overall impressions:

Installation was very smooth and painless for an "alpha" release, no complaints.

The general arm64 Linux ecosystem is in pretty good shape, which is reassuring and bodes well for a server style installation of Asahi Linux.

2022 is the year of Linux on the desktop, and cut/copy/paste key bindings still trip me up.

Page size bugs are the bugs that keep on giving, and are still affecting aarch64 software development years after they were first described and identified.