Some ideas to make pipedal easier to setup and use by non-techy people

[FoolHen]

I have been thinking about giving a friend a rpi with pipedal, and thought about the issues he would face, as he is not tech literate at all. And I thought that some improvements could help him and potential pipedal users, potentially expanding its demographic. This is more of a discussion than a feature requests, as it's all up to @rerdavies to decide.

First of all I belive the installation of plugins is the biggest drawback. If pipedal were already configured, users would be able to use it without having to interact with linux at all. But when it comes to adding lv2 pluggins they would need to use it. I think pipedal would be able to allow uploading plugins that you have on your phone/pc (similar to other files for NAM or ToobAmp for example), and it could manage their installation. This would need some kind of management where you can see the plugins installed and their versions, and see if you have it already installed or it's an update etc. Additionally, and more user-friendly, would be to implement a "store" interface where you can browse existing ones from a source (or potentially more than one). An example would be PatchStorage. It provides an API for this, where you can filter by the plugin type and architecture. It has support for lv2 aarch64.

Another potential topic for improvement would be handling the wifi connections from pipedal. This is a bit complicated. The first time you use pipedal after installing it it does not start a wifi hotspot because it expects that you have connected the rpi to a network before to install pipedal. I would argue that it would be better to set the wifi hotspot to "enabled when no known connection is found" option by default, with a default name and password for the hotspot. That way an sd card with pipedal installed would work without having to set a wifi name and password. Additionally I thought that the UI could support the option to connect the rpi to wifi networks. That way if the user connects though the hotspot they can configure the pipedal networks from it. This could make it possible to manage the connections without needing to use linux.

But what happens if the user sets the connection to never use hotspot and then they are in a place where their wifi is not availabe, or they change their wifi password or name? This would "brick" them, so to say. I thought about the possibility of adding a hardware button for this usecase, that would enable the hotspot, with default settings. That way it would also help if the user forgets the hotspot password. But for the button to work pipedal might need a command to trigger that. I can't think of a software-only solution though.

What do you think? Is there something else that also could be streamlined for non-techy users? Eager to hear your thoughts.

[rerdavies]

A very good perspective to take, thanks.

By way of discussion (nothing firm at this point). I'm definitely open to further discussion on this topic, and far too TLDR, because I'm using this as an opportunity to brainstorm some of the very real issue involved.

Default wifi hotspot configuration.

I agree that bringing up the hotspot if there's no active wifi connection should be harmless. But, as a first reaction, , having a default password on a wi-fi hotspot is a not-insignificant point of concern for me. Maybe if I tightly firewalled the hotspot network. And maybe if I implement a Web Capture portal that remains active until the user has chosen a Wi-Fi password... I need to give that some thought. I'm more-or-less comfortable with the current situation, because the Wi-Fi connection is protected with a plausibly secure user-generated Wi-Fi password. I know, for example that my ssh server is visible on the hotspot connection. That would definitely need to be fixed. And Android makes some unpleasant demands on what has to be visible on a hotspot connection before it will allow the connection to succeed. So it's a complicated issue.

In the distant future, I've always imagined Pipedal becoming an IoT sort of device, where it gets installed assuming you will be running nothing else. Under those circumstances, I could comfortably see the Wi-Fi direct interface being brought up automatically (perhaps with a serial-number-based default password instead of a default password). Probably the best solution: PiPedal comes pre-installed on an rPI, and there's a sticker on the bottom of the case that gives the default wi-fi password for that box only.

The fundamental issue: silently bringing up a Wi-Fi hotspot connection with a default password is probably not a good idea. I have given some thought (a lot of thought actually) as to how to better deal with initial provision of PiPedal. But these are tough problems.

If you were to do it for your friend ahead of time, however, you could make sure there's a real effective password on the hotspot.

Uploading of LV2 plugins.

A serious security issue, I'm afraid. The web server connection is, very unfortunately, wide open when ethernet is connected to the rPi, and there's not a lot I can do about it. https/tls does NOT work on local network connections -- a deliberate and very frustrating decision made by various standards bodies. So I have to take great care to treat anything that gets uploaded via the web server with extreme caution. (multiple layers of security checks and permissioning to make sure that uploaded media files don't' go where they're not supposed to, for example, and multiple checks and cryptographic signature verification of the uploads). And a restriction on the number of network hops allowed on web server connections to prevent traffic to the web server from arriving through an open router.

I could cryptographically protect the web socket connection. But there's no easy way to establish initial trust without using web OATH servers (like Google login) that I can think of. And OAUTH services are not free. So there's that issue as well. And probably some real technical challenges getting OATH tokens from the user's browser to the PiPedal server over a non-https connection.

So uploading executable code through the web server is a really big and complicated and dangerous problem.

To the best of my knowledge, there doesn't seem to be an easy solution to this problem. For various technical reasons, Pipedal CANNOT use https connections (a fundamental design decision made by IETF engineers -- local networks CANNOT use https. And without https connections there's no sensible way to create a cryptographically secure connection to Pipedal for only trusted users. At least not that I'd trust myself to implement, or that non-technical users would be REMOTELY comfortable with. (Installing and/or creating PGP/GPG trusted keys is the most unpleasant UX that I have EVER seen -- even worse than the Windows experience).

Uploaded plugins would (1) probably need .deb packaging in order to instal properly, which would be able to execute code with root privileges, and (2) end up executing code in the pippedal service with minimal sandboxing. So completely out of the question without some sort of central signing authority and store-like infrastructure, which I don't honestly trust myself to implement adequately.

A potential solution would be to have a large bundle of pre-installable plugins that can be installed as a second step. But I am reluctant to build such a package myself, because a plauisble reading of GPL-3 is that it would end up infecting Pipedal source code with a GPL-3 license if I, myself, am distributing GPL licensed plugins. Not so much if other people are distributing them. One could plausibly argue that the LV2 plugin interface is a "system" interface, and therefore exempted by GPL-3; but that could end up being a very expensive argument to make. And I'm not sure that the LV2 Plugin interface really is a "system interface".

Perhaps, Pipedal could download and install a few odd apt-installable packages, which have actually been signed by Debian private keys, and install them through the web UI.

Perhaps, the pipedal .deb package could list some of the big LV2 bundles that are distributed via apt as dependencies. I was pleased to see Guitarix.lv2 and GxPlugins.lv2 are now distributed via APT, and would be good candidates. Some of the other LV2 bundles available through Debian servers (MDA for example).... I'm of two minds as to whether pre-installing them would actually be doing anyone any favors. They tend to have overly busy control interfaces, and tend to be.... not as well implemented as they could be .

The ultimate solution would be some kind of in-the-cloud store infrastructure (like MOD, but NOT like PatchStorage which is incredibly unsafe). PatchStorage is, unfortunately, not a solution, and is unlikely to ever be a solution.

And perhaps maybe running the plugins only in a real actual sandbox (a huge change, and a technical challenge that the biggest companies in the world struggle with). But It's possible that I could separate the web server to run in one sandbox, and the actual Pipedal model to run in another sandbox.

All negatives so far, I''m afraid. These are real and significant issue. But I'm open to suggestions on how to make this happen.

And I would be PARTICULARLY interested to know whether you have seen comparable Linux products that have managed to address these sorts of problems. MOD's solution is probably correct: a private store, and they build and modify and curate their own selection of LV2 plugins, while not allowing other LV2 plugins to be installed at all. Not feasible at Pipedal's current state of evolution.

The fundamental issue: how to establish an appropriate web of trust for code that gets uploaded to PiPedal. An almost impossible problem, I think.

If I were you, I would apt install Guitarix.lv2 and GxPlugins.lv2 on your friend's box before you give it to him. :-P That gives him 30 or 40 really exceptionally good plugins to get started with.

And maybe set up a chron job to automatically run apt update once in a while. (Adding a System/Check for system updates menu item might be a viable idea).

Sorry. Much much too TLDR.

[rerdavies]

Oh. Missed a couple:

Additionally I thought that the UI could support the option to connect the rpi to wifi networks. That way if the user connects through the hotspot they can configure the pipedal networks from it. This could make it possible to manage the connections without needing to use linux.

Yes. A very plausible feature!

Save for entering the wifi password over an unsecure http connection. Setting up a 4-way handshake encryption layer for passing secrets between client and server over the web socket: actually feasible. I might be able to find code for that somewhere from a trustable source. And Wi-Fi standards actually describe a procedure for doing 4-way handshake encryption (which is why I know about it). I do actually have most of the code to do the server-side setup for that already, and most of the client-side code as well.

Writing the 4-way shake encryption layer: ,,, seriously ninja code, with incredibly high prospects of getting it wrong. And a possibility of tripping over crypto US export restrictions.... Sigh. (Is there an ecryption library in web browser javascript? I think so).

But what happens if the user sets the connection to never use hotspot and then they are in a place where their wifi is not availabe, or they change their wifi password or name?

Urgh. But, they WOULD have to do both at the same time to really brick the device. And there is always the saving option of plugging in an Ethernet cable. Not sure if ethernet connections auto-null these days. I think they do. (plug an ethernet cable between the two devices with no intervening router). Once, a very long time ago, you had to use a "crossover ethernet cable", which was potentially device-killing if used incorrectly. But I think that's no longer the case. I think that one's actually ok.

[rerdavies]

All sounding very negative. There are very real issues play. But keep the ideas coming. I do appreciate your input on this.

Maybe a script to run, post install to configure a raspberry pi as a turnkey IoT Pipedal device. Essentially a setup script for an actual IoT incarnation of PiPedal that probably won't arrive for some time. I could see setting up the Hotspot-by-default option under that scenario.

(suppresses discussion of problems with that in the spirit of brainstorming the problem).

[FoolHen]

Thanks for the detailed answer. Those are good points, I brainstormed those ideas without even thinking about security.

Unfortunately I don't know any other similar product, so I have no idea about that. It does seem like the cloud store sounds like the best approach. Maybe some open-source registry could be used to host things, but I guess that would require quite some work still, to configure, run, maintain it etc. Hopefully PatchStorage (if they address the issues you mentioned) or a similar existing alternative is enough.

Regarding the default wifi hotspot: I didn't think about Ethernet always being a failsafe. I think that is good enough, anyone can connect a rpi to a router or pc. And, as mentioned, if pipedal had a way to configure wifi networks in its interface, users could add a wifi network while connected through Ethernet.

[rerdavies]

Settling on the idea that I could implement a 4-way-handshake encryption layer to avoid sending the wifi password to the server in plain text format. And that I can fall back to 3-DES to avoid export restriction triggers if necessary. so maybe scratch that objection off the list. Not a happy piece of code to write though.

It's possible that I could use PatchSource as an on-device source for LV-2 plugins. Or even better, as a source on the android app -- which would allow me to intercept download requests in the web view and forward them to pipedal. See how that one plays out. I'm hoping to chat with the owner to see if I can convince him to sign packages; or provide me with assurances necessary to use the https certificate for PatchSource instead. I'm hoping to have a discussion with the owner of PatchSource about how the LV2 bundles for rPi are handled. And hoping I can slip in a cryptographic signature on the packages at that point.

A very good exercise to think these things through. And timely given that I'm hoping to do work with Patchsource to iron out their LV2 problems.

[FoolHen]

Sounds good. Hopefully you can find code for the handshake layer, because it sounds painful. And fingers crossed for a response from the PatchStorage guys!

[rerdavies]

Maybe Windows/Mac/Android/(Linux) apps that pushes LV2 bundles from PatchStorage to the device via SSH. And not that difficult now that WIndows 10 has a OS-provided SSH command. (Secure, and uses password authentication, which addresses a lot of concerns with remote installation of LV2 plugins ). AND avoids the issue of Debian packages running install actions with root privileges. AND! Plausibly doable to write code that pushes a Debian Package WITHOUT using apt, and rejects Debian packages that have actual install actions. No sensible LV2 plugin should have a Debian package action.

Could maybe even augment handling of PatchStorage LV2 bundles to scan for and install dependencies that PatchStorage is not currently dealing with. (Kind of issane for PatchStorage to assume that plugins don't have install dependencies). And then staged testing of the installed plugins to make sure they aren't missing dependencies.

[guysoft]

Hey, creator of OctoPi/CustomPiOS here, I could create a distribution you basically flash and boot and save the deb package installation phase, should not be too complicated.
Is that something you want?

I am just looking in to buidling pipedal using a Rpi 4 and MOTU M2.
Also thinking about getting a power supply and print something to take them all together.

[rerdavies]

Yes! Definitely interested. Although there are some issues I'd like to work through before that happens. It's something I had envisioned doing at some point in the future -- probably later rather than sooner. But it looks like your toolset makes it relatively easy. PiPedal has been steadily checking off features required to run without ever using an SSH or desktop logging. And it's probably most of the way there now. There are a few issues I'd need to give some thought to before a PiPedal image gets built. Off the top of my head... - Testing to make sure that my existing onboarding procedure doesn't create odd race conditions with the PiPedal auto-update procedure. I think I can handle a PiPedal upgrade before the onboarding procedure completes, but I'd like to test that. - Maybe give some thought to PiPedal web UI for performing apt upgrades of the OS (I have a secure service for doing Pipedal upgrades already, which I think could be used to do apt update/apt upgrade as well). As a pure IoT device this seems like a responsible thing to do. - Maybe give some thought to pre-installing some GPL-ed LV2 plugins as a starter set (mostly plugins that are already available through APT, I think). (And marking the ToobAmp plugins as "Favorite" by default. :-P ) PiPedal can't currently do that itself, because I am determined to not infect Pipedal's MIT licensed source code with GPL. But I can see bundling GPL3 plugins on an installer image Perhaps a few other issues as well. I need to think about it a bit more. Some questions for you: 1) What do you use for a distribution channel for your images? Github? 2) I *think* I can get by with using Pipedal's auto-update feature to deal with delivery of updated versions of PiPedal. Is there a plausibly automated procedure for generating new images with updated .deb packages? 2) I notice you use editing of a configuration file on the flashed image which strikes me as very sensible. Could we chat about that, a bit. It would definitely be nice to allow configuration of initial passwords for the primary login, for SSH access, initial Wi-Fi configuration and (in my case) perhaps initial configuration of the Pipedal's Wi-Fi Hotspot password if the image is going to be brought up without internet access (that might be a bad idea). 3) I presume you've struggled with security for running a wide open website for your routing software on a local network. I did notice that you (or owners of the routing software) have unsuccessfully explored the horror of trying to bring up an HTTPS site for an IOT device on a local network. Did you manage to arrive at any sensible solution for the HTTPS problem? Or is that an issue that's external to your project? 4) I'm not sure if you've noticed, but the Raspberry Pi Flash card imager has started prompting for whether to generate an SD Card for Raspberry Pi 4 or Raspberry 5. Is that something you currently deal with? I currently require a Raspberry Pi OS Bookworm install. (There is a Bullseye installer, but -- at this point -- is missing too many features, and is really no longer supportable, so I need to unpublish it). They have also added UI support for initial configuration of the flashed image as well -- default logins and passwords, enabling SSH, initial locale selection, and a few other things. I'm somewhat concerned that the Rpi4/Rpi5 customization may break installation of images based on the current version of Raspberry Pi Os. (Also a bit concerned that pre-selection of locale is completely broken in Raspberry Pi Imager as of two days ago, but that's a separate issue) 5) Do you manage to completely bypass *raspi-config,* or is that still a necessary part of your install procedure? If you're on Discord or Google Chat, perhaps we could arrange a quick meeting to explore these and other related issues and concerns. Regards, Robin Davies.

…

On Tue, Nov 19, 2024 at 7:19 AM Guy Sheffer ***@***.***> wrote: Hey, creator of OctoPi/CustomPiOS here, I could create a distribution you basically flash and boot and save the deb package installation phase, should not be too complicated. Is that something you want? I am just looking in to buidling pipedal using a Rpi 4 and MOTU M2. Also thinking about getting a power supply and print something to take them all together. — Reply to this email directly, view it on GitHub <#243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXK2DBSFNNDHKQZ443W4U32BMUFNAVCNFSM6AAAAABQZY5LX2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZQGQZTAOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[guysoft]

1. I have both a CI/CD jenkins build and also github actions.
2. Sure, there is a discord for CustomPiOS if you wanna visit :) I am pretty busy these days but should manage to get to it eventually. I really should first install it myself and play with it first.
   2 (the second 2). There are a few methods, we can find what works best for PiPedal. Yo can always add your own too. We could also try to ask to get it in to RPi Imager's list. Or you can use the pi imager I (sort of) maintain (https://github.com/guysoft/pi-imager)
3. Gina on Octoprint has plenty of rants about the subject for example this one. We have not found a way around it apart from just using a self-signed certificate. Its a problem that modern browsers have that behavior.
4. I think we should build a bookworm install. The way they prompt is part of the rpi-imager json format. You can just add what you support, and as long its bookworm it should work on all pis that are usable today. CustomPiOS has an option to generate for you a rpi-imager snipplet to make the json you need for an rpi-imager publish. But you need to string them together yourself, for example here is the code I use to do that on my image hosting server.
5. You can in the end just see what the shell script does and do it yourself. I think we covered all of those needed so far in the modules. The only issue is that if they change the behavior of raspi-config we need to keep up.

And we can talk as I said in section 2 :)
I am busy at work and home stuff since I have a toddler around, but come to the CustomPiOS discord and we can talk