Snapcraft

tl;dr: There’s a relentless campaign by scammers to publish malware in the Canonical Snap Store. Some gets caught by automated filters, but plenty slips through. Recently, these miscreants have changed tactics - they’re now registering expired domains belonging to legitimate snap publishers, taking over their accounts, and pushing malicious updates to previously trustworthy applications. This is a significant escalation.

Context

Snaps are compressed, cryptographically signed, revertable software packages for Linux desktops, servers, and embedded devices. They use standard security primitives in the Linux kernel alongside technology developed by Canonical for Ubuntu.

Previously…

Back in February, I blogged about a series of scam Bitcoin wallet apps that were published in the Canonical Snap store, including one which netted a scammer $490K of some poor rube’s coin.

The snap was eventually removed, and some threads were started over on the Snapcraft forum

Groundhog Day

Nothing has changed it seems, because once again, ANOTHER TEN scam BitCoin wallet apps have been published in the Snap Store today.

On Tuesday, I blogged about a series of Bitcoin scam apps published in the Canonical Snap store.

Edit: This section updated on 2024-02-23 to include a Canonical response as two new forum posts from sabdfl (Mark Shuttleworth, CEO of Canonical).

Two things! Three things!

Zerothly, today we have a response from Canonical.

There are actually two new posts from Mark. One in response to the thread asking whether crypto apps should be banned from the Snap store, and the other an acceptance that identity verification might need to be stronger on the Snap store. Here they are in full:

Edit: There’s a short follow-up to this post: Exodus Bitcoin Wallet: Follow up.

tl;dr: A Bitcoin investor was recently scammed out of 9 Bitcoin (worth around $490K) in a fake “Exodus wallet” desktop application for Linux, published in the Canonical Snap Store. This isn’t the first time, and if nothing changes, it likely won’t be the last.

This post turned out longer than I expected. So if you don’t have the time there’s a briefer summary at the bottom under “In summary (the tl;dr)” along with my suggestions on what Canonical should do now.

The other day I wrote about snapcraft metrics, a tool that enables publishers to extract application metrics from the snap store. Something I’ve noticed which I wanted to share, was how quickly automatic updates roll out to an application’s user base.

So I took the metrics from an application that I published in the snap store and scrubbed the names and version numbers. I charted below the speed that devices roll over from one release to the next. Here’s an image that I think clearly shows the rapid rise as a new release is published, and the rapid drop-off, of the previous version. This chart covers a month where three versions were published, a week or so apart.

Agon and Agon

Last month I visited the RMC Cave where we got a sneak peek at the Agon Console8 from Heber. The Agon Console8 is a consolised version of the more general-purpose Agon8 Computer. They come in a natty retro case, and features twin 9-pin joystick ports.

I’d not heard about the Agon line of Open Source devices before, but they tickled something in me. I’m somewhat fascinated by computers that boot directly into BASIC.

I was a guest host on Late Night Linux podcast, episode 249 last week, filling in for Will. We each bring along a ‘discovery’, I brought snapcraft metrics to talk about. I thought I’d write up how I use them, for listeners of the show as it’s hard to articulate this very well verbally.

My snaps

I have about twenty snaps in the snap store. Some, like Bombsquad and ncspot have been published for years now. Others such as Classicube were more recently built and published.

I wrote previously about debugging a broken x16emu snap. In short, something went wonky with ld. I started a thread on the snapcraft forum and Ken VanDine came to my assistance with an answer and a pull request.

I grabbed that pr, and it did indeed build successfully..

$ snapcraft --use-lxd
Launching instance...
Executed: pull alsa-pulseaudio
Executed: pull gnome/sdk
Executed: pull x16-roms
Executed: pull x16-emulator
Executed: build alsa-pulseaudio
Executed: build gnome/sdk
Executed: build x16-roms
Executed: skip pull x16-roms (already ran)
Executed: skip build x16-roms (already ran)
Executed: stage x16-roms (required to build 'x16-emulator')
Executed: skip pull alsa-pulseaudio (already ran)
Executed: skip build alsa-pulseaudio (already ran)
Executed: stage alsa-pulseaudio (required to build 'x16-emulator')
Executed: build x16-emulator
Executed: skip stage alsa-pulseaudio (already ran)
Executed: stage gnome/sdk
Executed: skip stage x16-roms (already ran)
Executed: stage x16-emulator
Executed: prime alsa-pulseaudio
Executed: prime gnome/sdk
Executed: prime x16-roms
Executed: prime x16-emulator
Executed parts lifecycle
Generated snap metadata
Created snap package x16emu_b16509b_amd64.snap  

Even better, it’s smaller. The build I had in the store was 6MB in size:

I thought I’d “live blog” (not live) my way through fixing a snap which I noticed was broken this morning. How did I notice? I happened to look at the build page for it. Maybe my spidey sense was tingling, because I wouldn’t ordinarily have zoned in on this particular snap.

I could have some kind of alert that lets me know when this happens, but I currently don’t. I might use my new-found love of GitHub Actions, but that sounds like a future blog post!

Back in 2020 I stumbled on Bandwhich, a “Terminal bandwidth utilization tool”, written in Rust.

More recently, I was looking for a tool to identify which processes on a box were using bandwidth, and how much. I remembered Bandwhich and took another look. I wanted an easy way to install Bandwhich on a variety of machines, running a variety of Linux distributions across different architectures.

So I built a snap of bandwhich.