Increase security a bit

[nagyrobi]

A few small security feature requests:

• please at least implement an option to password-protect the whole web interface
• option to easily create builds without the Local Firmware Upload feature (eg. with a build parameter) and/or OTA

Reason: a malicious user if gets access to the (wifi) network, will be able to scan for squeezelite-esp32 devices, and by just entering the web interface, could simply upload a malicious binary to do nasty things. At least a strong password should be possible to be set to block unauthorized access.

For the "set it and forget it" - "never touch a running system" lazy kind of use cases best would be to simply remove any kind of ota possibility. Of course serial upgrade would still always remain possible, which can be planned.

[sle118]

"a few small security feature requests" unfortulately translates so a substantial amount of work for which I wish there could be some additional contributors to the project. I'll flag this as an enhancement but not sure when/if I will be able to get to it.

[nagyrobi]

With all respect, my intention was just to pin this to a todo list, so that it's not something to be forgotten.

[sle118]

I didn't mean to be rude or anything. You are bringing a good point.

I wish other developers would want to step in and contribute to the project so more of these asks could be addressed in parallel.

[emlynmac]

This is something I'd be interested in taking on, once I've got my boards made and the environment set up. I've got an unsupported DAC I want to use; so I've got a learning curve anyway.

[sle118]

Most i2s DAC are supported and i2c DAC can be initialized without a code change. But if needed, springra new DAC probably wouldn't take to much flash space.

I built the front end with webpack/bootstrap, and I have some basic framework implemented in the backend which I never got to finalize.

[emlynmac]

Most i2s DAC are supported and i2c DAC can be initialized without a code change. But if needed, springra new DAC probably wouldn't take to much flash space.

I built the front end with webpack/bootstrap, and I have some basic framework implemented in the backend which I never got to finalize.

Yup, I saw that and got it all figured out with a JSON blob to put in place. The DAC is the WM8711BL and is similar to the other supported WM series one; it needs the MCLK but has a much smaller register set.

I was able to get it partially working but not completely; I've not had time to debug yet. It seems that the I2C bus stops working once the MCLK is connected. Need to dig in...

[sle118]

There are typically two separate i2c buses. One for the display, Io expander, etc, and one that is used to send the DAC commands.

[sle118]

@emlynmac do you still have some bandwidth and motivation for the project?

[emlynmac]

@emlynmac do you still have some bandwidth and motivation for the project?

I do - just finishing off a hardware project so keen to dive into software now. I should probably get set up with a docker WSL environment huh?

[emlynmac]

@emlynmac do you still have some bandwidth and motivation for the project?

@sle118 Should I be using a 4.4 branch or something else?

[sle118]

@emlynmac I need to brush up the refactoring, which was stalled for a while due to real life priorities taking over. It's a new paradigm in which I went for protocol buffer to define a consistent set of structures to be used throughout the system. So I also revamped the build system quite a bit to auto-generate some c files, some python files (which I use to also create the base settings payloads in the system). I am also looking for a good java option that could be used to create a solid contract between the system and the front-end.... which at this point is up for the take for someone interested.

I also need to rethink the delivery mechanism for the updates as the UI and settings will be stored in a SPIFFS partition that gets shared between recovery and application. The OTA mechanism will need to be smart enough to update the app partition AND download the UI files (if they were updated).

If I recall, I was using the esp-idf version 4.4.6

The best for building the app is to use the docker image that matches the branch that is being maintained. The new branch will also have its own docker that you'll be able to use.

All in all, the new branch will be a bit of a step back. I did my best to preserve the functionality, but cutting out the reliance on NVS everywhere was quite a task and I am sure I broke a few pieces here and there.

Oh, and an interesting thing in the new branch is the fact that it will likely allow moving away from building multiple platforms; there will be preset config files in a "target" folder with small binary files containing all the settings that are hardware dependent and that users should not change. So when user sets a target name (e.g. squeezeamp), the system will always overwrite user settings with the content of these.

The goal here is to simplify the build process and update deliveries.

[emlynmac]

@emlynmac I need to brush up the refactoring, which was stalled for a while due to real life priorities taking over. It's a new paradigm in which I went for protocol buffer to define a consistent set of structures to be used throughout the system. So I also revamped the build system quite a bit to auto-generate some c files, some python files (which I use to also create the base settings payloads in the system). I am also looking for a good java option that could be used to create a solid contract between the system and the front-end.... which at this point is up for the take for someone interested.

I also need to rethink the delivery mechanism for the updates as the UI and settings will be stored in a SPIFFS partition that gets shared between recovery and application. The OTA mechanism will need to be smart enough to update the app partition AND download the UI files (if they were updated).

If I recall, I was using the esp-idf version 4.4.6

The best for building the app is to use the docker image that matches the branch that is being maintained. The new branch will also have its own docker that you'll be able to use.

All in all, the new branch will be a bit of a step back. I did my best to preserve the functionality, but cutting out the reliance on NVS everywhere was quite a task and I am sure I broke a few pieces here and there.

Oh, and an interesting thing in the new branch is the fact that it will likely allow moving away from building multiple platforms; there will be preset config files in a "target" folder with small binary files containing all the settings that are hardware dependent and that users should not change. So when user sets a target name (e.g. squeezeamp), the system will always overwrite user settings with the content of these.

The goal here is to simplify the build process and update deliveries.

Just trying to get started here. I'm using WSL2, ubuntu installed.

cloned this repo; with recursion. got docker desktop set up with WSL2 support, docker run -it -v /home/emlyn/squeezelite-esp32:/squeezelite-esp32 sle118/squeezelite-esp32-idfv435

Then went into the squeezelite-esp32 and tried an idf.py build in the directory.

I'm getting an error:

CMake Error at squeezelite.cmake:7 (esptool_py_flash_project_args):
  Unknown CMake command "esptool_py_flash_project_args".
Call Stack (most recent call first):
  squeezelite.cmake:124 (___register_flash)
  CMakeLists.txt:11 (include)

Is there something I'm missing here?

Edit: I have got the 4.4 branch building with a fresh install of the espressif kit on WSL.

[sle118]

Glad you could make it. Now since you can't flash from wsl2, you can actually run the esptool.py from the build folder in a Windows folder. I am not in front of my computer right now so I can't give more details, but the build folder has flashing instructions

[emlynmac]

Oh, I can flash from WSL2.

Use https://github.com/dorssel/usbipd-win to pass the USB-serial for your board through to WSL and attach. In my case, I have a ch341 chipset, so sudo modprobe ch341 gets me the /dev/ttyUSB0. Then chmod it to rw and flash. I tested this with the basic hello world from ESP web site.

For the build of the 4.4-s3 branch, it seems that needs an 8M flash ESP32? I'm going to try getting the 4.3 IDF in WSL too, and I've got a couple of 8/8 ESP32 boards coming.

I also re-read the issue - this is for the password protection of the HTTP server, rather than the bluetooth PIN (another issue). I have only briefly looked through the web app and saw some reference to .htaccess files. Does this mean we can do HTTP Basic Auth, or is it going to need some rework of the app?

[nagyrobi]

Yeah and a way to prevent OTA with malicious binaries. Eg. with a DNS redirect etc.

[emlynmac]

@sle118 https://github.com/sle118/squeezelite-esp32/blob/master-v4.3/components/wifi-manager/http_server_handlers.c#L218 How does this work with the web app code?

EDIT: I got an image built and flashed too, so maybe I'll just start playing.

[nagyrobi]

Another good example is WLED, where they implemented a quite intuitive OTA Lock feature to prevent flashing of malicious firmware.

[sle118]

@nagyrobi thank you for pointing this out. The thing is without some help, this will be difficult to implement. Over the years, a massive amount of spare time from @philippe44 and myself has sunk into this project and I had to take a bit of distance to recharge.

As I wrote earlier, I will commit the new version, which has a better foundation overall, but I have to find the motivation.

@emlynmac yes it is possible to implement basic auth. In fact, you will see that I had planned for this originally with some hooks in each one of the http handlers.

[nagyrobi]

Totally understand. @sle118 @philippe44 your work that you've put over the years into this is way too valuable to be muddled up by any possible negative incident. That's just the reason why I keep reminding this.

[emlynmac]

@nagyrobi thank you for pointing this out. The thing is without some help, this will be difficult to implement. Over the years, a massive amount of spare time from @philippe44 and myself has sunk into this project and I had to take a bit of distance to recharge.

As I wrote earlier, I will commit the new version, which has a better foundation overall, but I have to find the motivation.

@emlynmac yes it is possible to implement basic auth. In fact, you will see that I had planned for this originally with some hooks in each one of the http handlers.

I made use of the long weekend. PR up for review for basic auth. I haven't used C in a while...